Test Driven Sysadmin

TDD FOR SYSADMINS Johan van den Dorpe

Friday, 9 December 2011

TOPICS

• Best Practice in IT

• Test Driven Development

•Discussion

• Behaviour Driven Development?


SYSADMIN BEST PRACTICES

• ITIL

• ASL

• ISO9000, COBIT...

•Manuals

•Web / HOWTOs

•Word of mouth

• Tradition

• Experience


DEVELOPER BEST PRACTICES

• eXtreme Programming (XP)

• Agile

•DSDM

• Adaptive

• SCRUM

•Object orientation

• Refactoring

• Test driven development

• Aspect oriented development

• Use cases...


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.


http://en.wikipedia.org/wiki/Test_case

http://en.wikipedia.org/wiki/Test_case

http://en.wikipedia.org/wiki/Code_refactoring

http://en.wikipedia.org/wiki/Code_refactoring

NORMALLY...

Design

Implement

Test


TDD

Design

Test

Implement


TDD

Design

Test

Implement

Test


TDD

Design

Test

Implement

Test


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


BENEFITS

• Ensures that code is written for testability

• Ensures unit tests are written for all code

• Tests provide documentation about functionality


BENEFITS

• Ensures that configurations are developed for testability

• Ensures unit tests are written for all configurations

• Tests provide documentation about functionality


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





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

• Ignore failing checks!


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


RED GREEN REFACTOR



•Make tests part of automated testing cycle

•Make test visible to everyone

• Test everywhere: dev, test and live

• Tests can be used by SSA



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

• Implementation won’t be easy


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


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.


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?


DISCUSS


NOT A TEST


A TEST


FAILED TEST - RED


PASSED TEST - GREEN


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


CUCUMBER


CUCUMBER


CUCUMBER


CUCUMBER


CUCUMBER NAGIOS


Technology

Test Driven Sysadmin