2. TOPICS
• Best Practice in IT
• Test Driven Development
• Discussion
• Behaviour Driven Development?
Friday, 9 December 2011
3. SYSADMIN BEST PRACTICES
• ITIL • Manuals
• ASL • Web / HOWTOs
• ISO9000, COBIT... • Word of mouth
• Tradition
• Experience
Friday, 9 December 2011
4. DEVELOPER BEST PRACTICES
• eXtreme Programming (XP) • Object orientation
• Agile • Refactoring
• DSDM • Test driven development
• Adaptive • Aspectoriented
development
• SCRUM
• Use cases...
Friday, 9 December 2011
5. 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
6. NORMALLY...
Design
Implement
Test
Friday, 9 December 2011
7. TDD
Design
Test
Implement
Friday, 9 December 2011
8. TDD
Design
Test
Implement
Test
Friday, 9 December 2011
9. TDD
Design
Test
Implement
Test
Friday, 9 December 2011
10. 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
11. 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
12. 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
13. WHAT DO WE DO, TODAY?
• We have identified the need for automated testing of builds
and configurations
Friday, 9 December 2011
14. 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
15. 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
16. 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
17. 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
19. 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
20. 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
21. 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
22. 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
23. 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
29. 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