Your SlideShare is downloading. ×
Test Driven Sysadmin
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Test Driven Sysadmin

477

Published on

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

No Downloads
Views
Total Views
477
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. TDD FOR SYSADMINS Johan van den DorpeFriday, 9 December 2011
  • 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 • ExperienceFriday, 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 TestFriday, 9 December 2011
  • 7. TDD Design Test ImplementFriday, 9 December 2011
  • 8. TDD Design Test Implement TestFriday, 9 December 2011
  • 9. TDD Design Test Implement TestFriday, 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 PASSFriday, 9 December 2011
  • 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. 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. WHAT DO WE DO, TODAY? • We have identified the need for automated testing of builds and configurationsFriday, 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 testsFriday, 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 validatingFriday, 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 PASSFriday, 9 December 2011
  • 18. RED GREEN REFACTORFriday, 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 SSAFriday, 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 easyFriday, 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 passFriday, 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
  • 24. DISCUSSFriday, 9 December 2011
  • 25. NOT A TESTFriday, 9 December 2011
  • 26. A TESTFriday, 9 December 2011
  • 27. FAILED TEST - REDFriday, 9 December 2011
  • 28. PASSED TEST - GREENFriday, 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 detailsFriday, 9 December 2011
  • 30. CUCUMBERFriday, 9 December 2011
  • 31. CUCUMBERFriday, 9 December 2011
  • 32. CUCUMBERFriday, 9 December 2011
  • 33. CUCUMBERFriday, 9 December 2011
  • 34. CUCUMBER NAGIOSFriday, 9 December 2011

×