Test Driven Sysadmin

750 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
750
On SlideShare
0
From Embeds
0
Number of Embeds
48
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Test Driven Sysadmin

  1. 1. TDD FOR SYSADMINS Johan van den DorpeFriday, 9 December 2011
  2. 2. TOPICS • Best Practice in IT • Test Driven Development • Discussion • Behaviour Driven Development?Friday, 9 December 2011
  3. 3. SYSADMIN BEST PRACTICES • ITIL • Manuals • ASL • Web / HOWTOs • ISO9000, COBIT... • Word of mouth • Tradition • ExperienceFriday, 9 December 2011
  4. 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. 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. 6. NORMALLY... Design Implement TestFriday, 9 December 2011
  7. 7. TDD Design Test ImplementFriday, 9 December 2011
  8. 8. TDD Design Test Implement TestFriday, 9 December 2011
  9. 9. TDD Design Test Implement TestFriday, 9 December 2011
  10. 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 PASSFriday, 9 December 2011
  11. 11. BENEFITS • Ensures that code is written for testability • Ensures unit tests are written for all code • Tests provide documentation about functionalityFriday, 9 December 2011
  12. 12. BENEFITS • Ensures that configurations are developed for testability • Ensures unit tests are written for all configurations • Tests provide documentation about functionalityFriday, 9 December 2011
  13. 13. WHAT DO WE DO, TODAY? • We have identified the need for automated testing of builds and configurationsFriday, 9 December 2011
  14. 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 testsFriday, 9 December 2011
  15. 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 validatingFriday, 9 December 2011
  16. 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. 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 PASSFriday, 9 December 2011
  18. 18. RED GREEN REFACTORFriday, 9 December 2011
  19. 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 SSAFriday, 9 December 2011
  20. 20. TEST DRIVEN CONFIG MANAGEMENT • Anything being changed on the build server, or being migrated, should follow TDD • Implementation won’t be easyFriday, 9 December 2011
  21. 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 passFriday, 9 December 2011
  22. 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. 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
  24. 24. DISCUSSFriday, 9 December 2011
  25. 25. NOT A TESTFriday, 9 December 2011
  26. 26. A TESTFriday, 9 December 2011
  27. 27. FAILED TEST - REDFriday, 9 December 2011
  28. 28. PASSED TEST - GREENFriday, 9 December 2011
  29. 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 detailsFriday, 9 December 2011
  30. 30. CUCUMBERFriday, 9 December 2011
  31. 31. CUCUMBERFriday, 9 December 2011
  32. 32. CUCUMBERFriday, 9 December 2011
  33. 33. CUCUMBERFriday, 9 December 2011
  34. 34. CUCUMBER NAGIOSFriday, 9 December 2011

×