Test-Driven Development by Kent Beck

Posted by Matthias Günther
  • p 7: basics of TDD
    1. Add a little test
    2. Run all tests and fail (make it compile)
    3. Make a little change (run it to see that it fails)
    4. Run the tests and succeed
    5. Refactor to remove duplication
  • p 8: "Eliminating duplication in programs eliminates dependency."
  • p 47: Not write a new test, if we have a red bar
  • p 55: "Where design isn't obvious, fake the implementation and refactor."
  • p 147: "Code that isn't tested doesn't work"
  • p 153: Triangulation
    • first write a test with one assertion
    • the tested method returns a constant
    • then write another assert for the same method -> now you have to abstract the correct implementation of the method to make it pass
    • time to remove duplication
  • p 155: One to Many:
    • How do you implement an operation that works with collections of objects? Implement it without the collection first, then make it work with collections
  • p 160: "The goal of each test is to leave the world in exactly the same state as before it run."
  • p 165: "Most of the problems we solve are generated by the tools we use, not by the external problem at hand."
  • p 168: Aliasing problem: If two objects share a reference to a third, and if one object changes the shared object, then the other object better not rely on the state of the other object
  • p 168: Design pattern Value Object -> they avoid the aliasing problem
    • when implementing a value object, every operation has to return a fresh object, leaving the original object unchanged
  • p 169: Design pattern Null object -> How do you represent special cases using objects? Create a special object representing the special case
  • p 171: Design pattern Pluggable Object -> represents variation by invoking another object with two or more implementations
  • p 173: Design pattern Pluggable Selector -> avoid subclassing by dynamically invoking different methods for different instances.
    • only use this pattern in which most of the subclasses has only one method
  • p 174: Design pattern Factory Method -> Create an object by calling a method instead of a constructor
  • p 182: Isolate change
    • How do you change one part of a multi-part method or object?
    • First isolate the part that has to change
    • Possible ways are Extract Method, Extract Object, or Method Object
  • p 184: Extract Method: Make a long, complicated method easier to read
    1. Find a region of the method that would make sense as its own method.
    2. Make sure that there are no assignments to temporary variables declared outside the scope of the region to be extracted.
    3. Copy the code from the old method to the new one.
    4. For each temporary variable or parameter of the original method used as the new method, add a parameter to the new one.
    5. Call the new method from the original method.
  • p 185: Inline Method: Simplify control flows that are to twisted
    1. Copy the method.
    2. Paste the method over the method invocation.
    3. Replace all formal parameters with actual parameters.
  • p 187: Move Method: Move the method to the place where it belongs and invoke it from there
    1. Copy the method.
    2. Paste the method, suitable named, into the target class and compile.
    3. If the original object is referenced in the method, then add a parameter to pass the original subject: If variables of the original object are referenced, then pass them as parameters. If variables of the original object are set, then you should give up.
    4. Replace the body of the original method within an invocation of the new method.
  • p 189: Method Object: Present a complicated method that requires several parameters and local parameters as an object
    1. Create an object with the same parameter as the method
    2. Make 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()
    5. good for simplifying code that doesn't yield to Extract Method
    6. sometimes the extracted method doesn't look better as the original code cause of six or more parameters
    7. creating method objects gives you a new namespace in which you can extract methods without having to pass anything
  • p 194: What don't you have to test? Write tests until fear is transformed into boredom
  • p 194: What should you test?
    • conditionals
    • loops
    • operations
    • polymorphism
  • p 198: When to delete a test
    • Confidence: Never delete a test if it reduces your confidence in the behavior of your system
    • Communication: Two tests that exercise the same path through the code, but speak different scenarios for a reader, leave them alone
    • delete tests that are redundant with respect to confidence and communication
  • p 202: Benefits of TDD
    • stop building breaks and people can rely on my software to work
    • customers of system become more positive
    • reduced defects
    • reduced the feedback loop of design decisions