Test-Driven Development
1 like161 views
This document summarizes notes from Kent Beck's book "TDD by Example" on test-driven development (TDD). It outlines the core principles of TDD, including writing tests first before code and eliminating duplication. It also describes techniques like red-green-refactor cycles where tests are written to fail initially ("red"), made to pass ("green"), and then code is refactored. The document provides examples of applying TDD to a money conversion problem and discusses patterns for testing, refactoring, and overcoming fears that arise during the process.
Test-Driven Development
- 1. TDD Amir Asaad (asaad.amir@icloud.com) 4 January 2021 Notes from TDD by example by Kent Beck
- 2. Two simple rules • Don’t write a line of new code unless you first have a failing automated test. • Eliminate duplication. 2
- 3. The TDDs mantra* Red/green/refactor • Red—write a little test that doesn’t work, perhaps doesn’t even compile at fi rst • Green—make the test work quickly, committing whatever sins necessary in the process • Refactor—eliminate all the duplication created in just getting the test to work 3 (*) a mystical formula of invocation (as in Hinduism)
- 4. Fear If pain is nature’s way of saying “Stop!”, fear is nature’s way of saying “Be careful.” The problem is that fear has a host of other effects: • Makes you tentative • Makes you grumpy • Makes you want to communicate less • Makes you shy from feedback 4
- 5. • None of these effects are helpful when programming, especially when programming something hard. So, how can you face a dif cult situation and • Instead of being tentative, begin learning concretely as quickly as possible. • Instead of clamming up, communicate more clearly. • Instead of avoiding feedback, search out helpful, concrete feedback. • (You’ll have to work on grumpiness on your own.) 5
- 6. Rhythms of DDT 1. Quickly add a test 2. Run all the tests and see thew new one fail 3. Make a little change 4. Run all the tests and make them all success 5. Refactor to remove duplication 6
- 7. • How each test can cover a small increment of functionality • How small and ugly the changes can be to make the new tests run • How often the tests are run • How many teensy tiny steps make up the refactoring 7
- 8. Money Example • What object do we need fi rst? Trick question. We don’t start with objects, we start with tests • What test do we need fi rst? • Start small or not at all. • To do: 1. $5 + 10 CHF = $10 if CHF:USD is 2:1 2. $5 * 2 = $10 8
- 9. • When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won’t always come true, but better to start from the best possible API and work backwards than to make things complicated, ugly, and “realistic” from the get go. • public class TestMoney extends TestCase { public void testMultiplication(){ Dollar fi ve = new Dollar(5); fi ve.times(2); assertEquals(10, fi ve.amount); } }
- 10. Dependency and Duplication If dependency is the problem, duplication is the symptom. Duplication also appears in data. Unlike most problems in life, where eliminating the symptoms only makes the problem pop up elsewhere in worse form, eliminating duplication in programs eliminates dependency. That’s why the second rule appears in TDD. • 10
- 11. These are two of the three strategies for quickly getting to green: • Fake It—return a constant and gradually replace constants with variables until you have the real code • Obvious Implementation—type in the real implementation When everything is going smoothly and I know what to type, I put in obvious implementation after obvious implementation (running the tests all the time to ensure that what’s obvious to me is still obvious to the computer). As soon as I get an unexpected red bar, I back up, shift to faking implementations, and refactor to the right code. When my con dence is back, I go back to obvious implementations. 11
- 12. Triangulation • Translated a design objection (side effects) into a test case that failed because of the objection • Got the code to compile quickly with a stub implementation • Made the test work by typing in what seemed like the right code 12
- 13. By analogy, when we triangulate, we only generalize code when we have two more examples. We brie fl y ignore the duplication between test and model code. When the second example demands a more general solution, then and only then do we generalize. What axes of variability are you trying to support in your design? Make some of the them vary and the answer may become clearer. 13
- 14. Good design at good times. Make it run, make it right. The different phases have different purposes. They call for different styles of solution, different aesthetic viewpoints. The first three phases need to go by quickly, so we get to a known state with the new functionality. You can commit any number of sins to get there, because speed trumps design, just for that brief moment. 14
- 15. Teeny-tiny steps This is the kind of tuning you will be doing constantly with TDD. Are the teeny-tiny steps feeling restrictive? Take bigger steps. Are you feeling a little unsure? Take smaller steps. TDD is a steering process—a little this way, a little that way. There is not right step size, now and forever. • 15
- 16. Here is another general pattern of refactoring —take code that works in one instance and generalize it to work in many by replacing constants with variables. • 16
- 17. This is a positive feedback loop. The more stress you feel, the less testing you will do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel. Rinse and repeat. • 17
- 18. Patterns for Test-Driven Development • Test n. How do you test your software? Write an automated test. • Isolated Test How should the running of tests affect each other? • Test List The more experience I accumulated, the more things I knew that might need to be done. The more things I knew might need to be done, the less attention I had for what I was doing. The less attention I had for what I was doing, the less I accomplished. The less I accomplished, the more things I knew that needed to be done. • 18
- 19. • Test-First • Assert-First • Where should you start building a system? With the stories that you will be able to tell about the system when it is done. • Where should you start writing a bit of functionality? With the tests that will run when it is done. • Where should you start writing a test? With the asserts that will pass when it is done. • Test Data Use data that makes the tests easy to read and follow. • Evident Data assertEquals(new Note(49.25, "GBP"), result); assertEquals(new Note(100 / 2 * (1 - 0.0015), "GBP"), result); • 19
- 20. Implementation Strategies • Fake It (‘Til You Make It) • Triangulate • Obvious Implementation Fake It and Triangulation are teensy-weensy tiny steps. Sometimes you are sure you know how to implement an operation. Go ahead. • One to Many How do you implement an operation that works with collections of objects? Implement it without the collections rst, then make it work with collections. • 20
- 21. Process These patterns are about when you write a test, where you write tests, and when you stop • One Step Test Pick a test that will teach you something and that you are con dent you can implement. • Starter Test Which test should you start with? Start by testing a variant of an operation that doesn't do anything. • Explanation Test • Another Test • Regression Test What's the fi rst thing you do when a defect is reported? Write the smallest possible test that fails, and that once it runs, the defect will be repaire • Break What do you do when you feel tired or stuck? Take a break. • Do Over What do you do when you are feeling lost? Throw away the code and start over. • Cheap Desk, Nice Chair 21
- 22. Testing Techniques Child Test How do you get a test case running that turns out to be too big? Write a smaller test case that represents the broken part of the bigger test case. Get the smaller test case running. Reintroduce the larger test case. Mock Object How do you test an object that relies on an expensive or complicated resource? Create a fake version of the resource that answers constants. Self Shunt How do you test that one object communicates correctly with another? Have the object under test communicate with the test case instead of with the object it expects. 22
- 23. Log String How do you test that the sequence in which messages are called is correct? Keep a log in a string, and append to the string when a message is called. Crash Test Dummy How do you test error code that is unlikely to be invoked? Invoke it anyway with a special object that throws an exception instead of doing real work. Broken Test How do you leave a programming session when you’re programming alone? Leave the last test broken. Clean Check-in How do you leave a programming session when you’re programming in a team? Leave all the tests running. don’t give up on running the whole suite all the time until it is slow enough to be annoying 23
- 24. Refactoring It’s no excuse to say, “I knew there was a problem, but the tests all passed so I checked the code in.” Write more tests. • Reconcile Differences How do you unify two similar looking pieces of code? Gradually bring them closer. Unify them only when they are absolutely identical. “A long chain of reasoning leads you to believe that the change you are about to make won’t change any answers. Those are the refactorings that enhance your hairline.” • Isolate Change return new Note(source.amount / rate, currency) return new Note(source.amount / fi ndRate(), currency) private int fi ndRate() { return rate; } Some possible ways to Isolate Change are Extract Method (the most common), Extract Object, and Method Object. 24
- 25. Migrate Date How: Here is the internal-to-external version: 1. Add an instance variable in the new format 2. Set the new format variable everywhere you set the old format 3. Use the new format variable everywhere you use the old format 4. Delete the old format Change the external interface to re fl ect the new format Sometimes, though, you want to change the API fi rst. Then you should: 1. Add a parameter in the new format 2. Translate from the new format parameter to the old format internal representation 3. Delete the old format parameter 4. Replace uses of the old format with the new format 5. Delete the old format Why: One to Many creates a data migration problem every time. 25
- 26. Method Object How: 1. Create an object with the same parameters as the method. 2. Make the local variables also instance variables of the object. 3. Create one method called "run()", whose body is the same as the body of the original method. 4. In the original method, create a new object and invoke run(). Why: Method Objects are useful in preparation for adding a whole new kind of logic to the system Method Objects are also good for simplifying code that doesn’t yield to Extract Method Extract a piece of code with too many variables and parameters you have to carry along resulting extracted method with long signature. Creating a Method Object gives you a new namespace in which you can extract methods without having to pass anything. 26
- 27. Add Parameter How: 1. If the method is in an interface, add the parameter to the interface rst 2. Use the compiler errors to tell you what other code you need to change Why: Adding a parameter is often an extension step. You got the rst test case running without needing the parameter, but in this new circumstance you have to take more information into account in order to compute correctly. Adding a parameter can also be part of migrating from one data representation to another. First you add the parameter, then you delete all uses of the old parameter, then you delete the old parameter. 27
- 28. Method Parameter to Constructor Parameter How: 1. Add a parameter to the constructor 2. Add an instance variable with the same name as the parameter 3. Set the variable in the constructor 4. One by one, convert references to “parameter” to “this.parameter” 5. When no more references exist to the parameter, delete the parameter from the method and all caller 6. Remove the now-super fl uous “this.” from references 7. Rename the variable correctly Why: If you pass the same parameter to several different methods in the same object, you can simplify the API by passing the parameter once (eliminating duplication). You can run this refactoring in reverse if you nd that an instance variable is only used in one method. 28
- 29. Why does TDD work? “Adopt programming practices that "attract" correct code as a limit function, not as an absolute value. If you write UnitTests for every feature, and if you Refactor to simplify code between each step, and if you add features one at a time and only after all the UnitTests pass, you will create what mathematicians call an "iterative dynamic attractor”(*).This is a point in a state space that all flows converge on. Code is more likely to change for the better over time instead of for the worse; the attractor approaches correctness as a limit function.“ (*) Dynamic Attractor (link) 29