test driven sysadmin
TRANSCRIPT
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