Upcoming SlideShare
×

# TDD and Related Techniques for Non Developers (2012)

442 views
323 views

Published on

A presentation I gave last year about TDD special for non technical people like project managers and managers.

Published in: Technology
0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
442
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
3
0
Likes
0
Embeds 0
No embeds

No notes for slide

### TDD and Related Techniques for Non Developers (2012)

1. 1. Test Driven Development and Related Techniques For Non-Developers ;-) IBM 2012 Peter Kofler, ‘Code Cop’ @codecopkofler www.code-cop.org Copyright Peter Kofler, licensed under CC-BY.
2. 2. Peter Kofler• Ph.D. (Appl. Math.)• (Java) Software Developer• with IBM since 1 year• SDM Costing, IGA, GBS
3. 3. The opinions expressed here are myown and do not necessarily represent those of current or past employers.
4. 4. Agenda1) What does it look like?2) Why is it important?3) What you need to do!4) Summary
5. 5. 1) So what is it all about?The Prime Factors Kata (Demo)
6. 6. What Exactly Will We Do Now?● write code together● using TDD● see techniques and patterns● discuss while doing
7. 7. The Requirements.• Write a class named “PrimeFactors” that has one static method: generate. – The generate method takes an integer argument and returns a List<Integer>. – That list contains the prime factors in numerical sequence. http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata
8. 8. First Some Math.● Prime Number: a natural number > 1that has no divisors other than 1 and itself. ● e.g. 2, 3, 5, 61, 67, ..., 997, ..., 243112609-1, …● Prime Factors: the prime numbers thatdivide an integer exactly without remainder. ● e.g. 2 = 2, 4 = 2 * 2, 24 = 2 * 2 * 2 * 3 288 = 25 * 32
9. 9. The Requirements (for Mortals).• code a file/module/class “PrimeFactors”• code a function/method/routine “generate”• accept an integer number as parameter• return the prime factors of that number
10. 10. Demo(Code Kata)
11. 11. Keep the bar green to keep the code clean.
12. 12. Unit Testing• test individual units• isolate each part• show that the individual parts are correct• regression testing• sort of living documentation• executed within a framework http://en.wikipedia.org/wiki/Unit_testing
13. 13. Test-Driven Development• add a test• run all tests and see if the new one fails• write some code• run all tests and see them succeed• refactor code mercilessly• „Red Green Refactor“ http://en.wikipedia.org/wiki/Test_Driven_Development
14. 14. A minute ago alltheir code worked
15. 15. Refactoring Refactoring is a technique for restructuring an existing body of code,altering its internal structure without changing its external behavior. (Martin Fowler)
16. 16. Refactoring• small behavior preserving transformations• sequence of transformations produce a significant restructuring• each transformation is small, less likely to go wrong• system is kept fully working after each change• verified by working tests
17. 17. Code Coveragecomprehensiveness of tests
18. 18. Beware!comprehensiveness  quality!
19. 19. Small AdviceNever measuredevelopers byCode Coverage!
20. 20. Demo(Coverage in Eclipse)
21. 21. Demo (Jenkins)
22. 22. ContinuousIntegration
23. 23. Continuous Integration• Maintain a code repository• Automate the build• Make the build self-testing• Everyone commits every day• Every commit should be built• Keep the build fast• Everyone can see the results of the build http://en.wikipedia.org/wiki/Continuous_integration
24. 24. Immediate Feedback and Early Warning
25. 25. Demo (Jenkins)
26. 26. 2) Why should we use TDD?• Writing tests takes time• and we need to deliver client value. I dont have time. I dont have time. I dont have time.
27. 27. Do you still use that one?
28. 28. Discussion• What do you think are the benefits of TDD? – rapid feedback –… – ...
29. 29. Benefits• speed up• coverage – measurable validation of correctness• quality – proven to save maintenance costs• creates a detailed specification
30. 30. Benefits• improve design – drive the design of a program – think in exposed API
31. 31. Problems• missing management buy-in• high ramp-up time• still need integration testshttp://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/
32. 32. TDD will not fix missing skills!• badly written tests – brittle – blinking – slow – duplicate code – maintenance burden – wrong abstractions – not really unit tests
33. 33. Because TDD is hard!• need to know OO, design, abstraction, ...• new style of thinking• need self-discipline• (learning curve)
34. 34. 3) What you need to do
35. 35. Problem Indicators: CI• blinking builds• builds broken for long time• increasing build execution time• decreasing code coverage
36. 36. Problem Indicators: Tests• slow• fragile• no detailed feedback• “Ice-Cream Cone”
37. 37. Problem Indicators: Developers• claiming that they cant write tests• claiming that they cant fix tests• wanting to delete tests
38. 38. “Buzzwords” Summary• Techniques – Unit Testing – Test Driven Development – Refactoring – Code Coverage – Continuous Integration• Management Buy-In• Keep an eye on the CI server
39. 39. Support TDDDo not compromise on techniques!
40. 40. Thank You
41. 41. Peter Kofler @codecopkoflerwww.code-cop.org
42. 42. CC Images• Drive: http://www.flickr.com/photos/hjem/367306587/• Judge: http://www.flickr.com/photos/eldave/6169431454/• List: http://www.flickr.com/photos/kylesteeddesign/3724074594/• Question mark: http://www.flickr.com/photos/oberazzi/318947873/• Fence: http://www.flickr.com/photos/30830597@N08/3630649274/• Coverage: http://www.flickr.com/photos/paulk/3166328163/• Works: http://www.codinghorror.com/blog/archives/000818.html• Cash: http://www.flickr.com/photos/mindfire/315274981/• Steep: http://www.flickr.com/photos/worldofoddy/229501642/• Want You: http://www.flickr.com/photos/shutter/105497713/• Warn: http://www.flickr.com/photos/hugosimmelink/2252095723/• Questions: http://www.flickr.com/photos/seandreilinger/2326448445/