TDD

My Experiences with TDD. Only 2nd & 3rd slide are in Spanish!

Transcript

1. Test-Driven Development My opinion & experiences Jonathan Cook & I like writing Unit Tests
2. Una Cosa, Juanma prefiere que yo hablo en Ingles! Lo siento!
3. Una Cosa mas, si hablo demasiado rapido, dime!
4. AGENDA • What is TDD - Recap • TDD Basics • Golden Rules of TDD • A word on Refactoring • Why the Business doesn’t like TDD. • Why I like TDD • Listening to the tests • Tips to help you make code more testable
5. AGENDA (continued) • What TDD is not! • TDD at The BBC • Summary • What’s next.
6. What is TDD? Recap
7. What is TDD? • The TDD cycle is very short. You write a test, write some code and get it working very quickly, every minute or two. • TDD is NOT JUST about testing. It gives you feedback on implementation quality and design quality. • Because you write the tests before the code, TDD makes testing a design activity.
8. At the heart of TDD?
9. TDD Basics
10. TDD Basics 1. Write the Assertion First and work backwards. You should get a compilation error. 2. Run the test to ensure it fails in the way you expect it to. 3. Write meaningful tests that are self explanatory.
11. TDD Basics (continued) 1. Triangulate through concrete examples to general solutions. 2. Isolate your tests so they run independently. 3. Maintain your tests.
12. TDD Basic (Continued) 1. Tests should test one thing. 2. Don’t refactor when a test is failing. 3. Keep you Test and Model code separate.
13. Golden Rules of TDD 1. NEVER EVER write new functionality unless you have a failing test. 2. You are not allowed to write any production code UNLESS it is to make a failing unit test pass. 3. You are NOT allowed to write any more production code than is sufficient to pass the one failing unit test.
14. A word on refactoring. What is it? Improving the code by: • Removing duplication • Making the code simpler • Making the code easier to read • Eliminate redundancy • Can be as simple as renaming a method • Should be done constantly, i.e every 2 or 3 minutes. Test code is INCLUDED and is as important - this is my documentation
15. Why the business doesn’t like TDD! • They think it is slow! At first there will be a slowing of delivery of new functionality, as the team gets used to using the TDD practice. But this is true of anything new, e.g) riding a bike, learning Spanish! • They think it will take longer because we need to write more code. But actually as we progress we can deliver new features with less or no bugs much more quickly. In my opinion I don’t think the business needs to know!
16. Why The Business (continued)
17. Why I like TDD! 1. Makes you think about what you are going to do. Gives you focus! 2. Lets you know when you've done enough. 3. Detects errors while the context is fresh in your mind. 4. When done properly, leaves a description of the system behind you. DOCUMENTATION! 5. Leaves a regression test suite behind you. 6. It is simple! I like simple things!
18. Why I like TDD (continued) 1. Gives you Confidence which lets you ship features quicker. 2. I know it works when I’ve finished 3. If someone changes it they will be notified if they have broken something 4. Quicker to fix bugs if you have any. What’s not to like?? :)
19. Listening to the Tests
20. Bad Tests! Bad names! This doesn’t tell me anything.
21. Bad Tests (continued) Avoid big tests. This is only half the test!
22. A Good Unit Test For an object must: 1. Instantiate the object 2. Provide its dependencies 3. Interact with it 4. Check that it behaves as expected
23. Good Tests Readable, easy to understand, do one thing!
24. Good Tests (continued) It doesn’t matter about language
25. Making your code more testable.
26. Tips to help you make code more testable! Avoid “Train Wreck” (train of getters) code like this.. client.GetMortgage().PaymentCollection(). GetNextPayment().ApplyPayment(300.00) • Its not pluggable • Objects are too tightly coupled • No one “normal” can understand it!
27. Tips to help you make code more testable! (Continued) Instead follow the “Tell don’t ask” principle.. client.ApplyMortgagePayment(300.00) Tell, Don't Ask helps make code easier to modify: • Localises information • Shields parts from change elsewhere • Forces you to name more concepts This makes writing tests easier!
28. Unit testing is difficult if... If a class is poorly designed. • Is tightly coupled to other parts of the system • Has hidden dependencies • Misuses information hiding (hides the wrong information) • Does too many things • Has unfocused responsibilities • Communicates by complicated protocols
29. Look for bad signs 1. Writing unit tests give you valuable, rapid feedback about design issues. 2. If it is difficult to write a test, you know something is wrong. 3. It is tempting to stop testing when it gets difficult. ◦ DON’T ◦ Investigate why the code is hard to test ◦ REFACTOR
30. What TDD is NOT
31. TDD is not magic! TDD will not solve all your problems. • You cannot derive a complete architecture with TDD. • TDD can inform some of your architectural decisions, but you cannot begin a project without an architectural vision. • So some up front architecture is necessary.
32. TDD is not Magic (continued) • There's no rule that states "when practicing TDD, you must not step back and look at the bigger picture. • You are allowed to think about the design before. • You are allowed to think about the “big picture”
33. TDD at The BBC
34. TDD at the BBC We practiced TDD at the BBC working in pairs. To get into the habit of writing the simplest code with practiced “Adversarial Pairing” One developer writes the test and passes the keyboard, the other makes the test pass in the simplest way. It’s good Fun!
35. TDD at the BBC (continued) We created a TDD Checklist which we used when working in pairs. Conclusion: • We wrote better code with less bugs • Working in pairs is hard work everyday • It takes discipline.
36. Summary
37. Its a mindset Practice it everyday with real examples! Get into the habit of writing a failing unit test for every piece of code you write for example: MOBILEWEB-787 - My info, Product: Incorrect alphabetic order of countries in drop down menus. Start with a failing testing and follow your checklist!
38. • More Unit - http://moreunit.sourceforge.net/ • JunitMax - http://junitmax.com/ Useful plugins for your IDE (Eclipse)
39. Not everyone likes it. Interesting article on some ideas why TDD is bad. • http://sanjaal.com/java/tag/why-tdd-is-bad/
40. Recommended Reading For me, these are the best books. • Growing object-oriented software guided by tests. • Test Driven Development by Example. • Refactoring - Improving the existing design of code.
41. Next time - An example? Si Quieres. Fibonacci Sequence Generator: Write some code to generate the Fibonacci sequence up to a specific length which is no shorter than 8 numbers and no longer than 50.
42. The End Espero que haya sido interesante! Y La proxima vez en Espanol a lo mejor!