Test Driven Sysadmin

Preview:

Citation preview

TDD FOR SYSADMINS Johan van den Dorpe

Friday, 9 December 2011

TOPICS

• Best Practice in IT

• Test Driven Development

•Discussion

• Behaviour Driven Development?

Friday, 9 December 2011

SYSADMIN BEST PRACTICES

• ITIL

• ASL

• ISO9000, COBIT...

•Manuals

•Web / HOWTOs

•Word of mouth

• Tradition

• Experience

Friday, 9 December 2011

DEVELOPER BEST PRACTICES

• eXtreme Programming (XP)

• Agile

•DSDM

• Adaptive

• SCRUM

•Object orientation

• Refactoring

• Test driven development

• Aspect oriented development

• Use cases...

Friday, 9 December 2011

WHAT IS TDD?

Test Driven Development relies on the repetition of a very short

development cycle: first the developer writes a failing automated

test case that defines a desired improvement or new function,

then produces code to pass that test and finally refactors the new

code to acceptable standards.

Friday, 9 December 2011

NORMALLY...

Design

Implement

Test

Friday, 9 December 2011

TDD

Design

Test

Implement

Friday, 9 December 2011

TDD

Design

Test

Implement

Test

Friday, 9 December 2011

TDD

Design

Test

Implement

Test

Friday, 9 December 2011

HOW TO DO IT

•Design: figure out what you want to do

• Test: write a test to express the design

• It should FAIL

• Implement: write the code

• Test again

• It should PASS

Friday, 9 December 2011

BENEFITS

• Ensures that code is written for testability

• Ensures unit tests are written for all code

• Tests provide documentation about functionality

Friday, 9 December 2011

BENEFITS

• Ensures that configurations are developed for testability

• Ensures unit tests are written for all configurations

• Tests provide documentation about functionality

Friday, 9 December 2011

WHAT DO WE DO, TODAY?

•We have identified the need for automated testing of builds and configurations

Friday, 9 December 2011

WHAT DO WE DO, TODAY?

•We have identified the need for automated testing of builds and configurations

• The testing team doesn’t have time to write the tests

Friday, 9 December 2011

WHAT DO WE DO, TODAY?

•We have identified the need for automated testing of builds and configurations

• The testing team doesn’t have time to write the tests

• Sometimes we write validation scripts - after we’ve implemented the configuration we’re validating

Friday, 9 December 2011

WHAT DO WE DO, TODAY?

•We have identified the need for automated testing of builds and configurations

• The testing team doesn’t have time to write the tests

• Sometimes we write validation scripts - after we’ve implemented the configuration we’re validating

• Ignore failing checks!

Friday, 9 December 2011

TEST DRIVEN CONFIG MANAGEMENT

•Design: figure out what you want to do

• Test: write a test to express the design

• It should FAIL

• Implement: defined desired configuration state & apply

• Test again

• It should PASS

Friday, 9 December 2011

RED GREEN REFACTOR

Friday, 9 December 2011

TEST DRIVEN CONFIG MANAGEMENT

•Make tests part of automated testing cycle

•Make test visible to everyone

• Test everywhere: dev, test and live

• Tests can be used by SSA

Friday, 9 December 2011

TEST DRIVEN CONFIG MANAGEMENT

• Anything being changed on the build server, or being migrated, should follow TDD

• Implementation won’t be easy

Friday, 9 December 2011

BENEFITS

• In future, when any change occurs we can re-run all tests to confirm the working state of the build

• The purpose of changes are more clearly defined - automated documentation

• If a configuration is requested - like a security change - we could request the tests are provided and we do the work to make them pass

Friday, 9 December 2011

BENEFITS

•Now we start to think of configuration as code. Can now use development methods and tools - revision control & code review.

• All requirements captured as tests

• Stronger process control around implementation of change - preventing unauthorised change in environments. Failed tests will alert.

Friday, 9 December 2011

TEST OR MONITOR?

• Is monitoring the equivalent of testing?

• Should test results be reported to existing testing infrastructure?

• Should test results be reported to monitoring infrastructure?

Friday, 9 December 2011

DISCUSS

Friday, 9 December 2011

NOT A TEST

Friday, 9 December 2011

A TEST

Friday, 9 December 2011

FAILED TEST - RED

Friday, 9 December 2011

PASSED TEST - GREEN

Friday, 9 December 2011

BDD

• First, obtain clear understanding of desired software behaviour - User Story

•Write test case in a natural language that non programmers can understand

• Look for the purpose and benefit of code rather than technical details

Friday, 9 December 2011

CUCUMBER

Friday, 9 December 2011

CUCUMBER

Friday, 9 December 2011

CUCUMBER

Friday, 9 December 2011

CUCUMBER

Friday, 9 December 2011

CUCUMBER NAGIOS

Friday, 9 December 2011