Make a little change (run it to see that it fails)
Run the tests and succeed
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
Find a region of the method that would make sense as its own method.
Make sure that there are no assignments to temporary variables declared outside the scope of the region to be
extracted.
Copy the code from the old method to the new one.
For each temporary variable or parameter of the original method used as the new method, add a parameter to the new
one.
Call the new method from the original method.
p 185: Inline Method: Simplify control flows that are to twisted
Copy the method.
Paste the method over the method invocation.
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
Copy the method.
Paste the method, suitable named, into the target class and compile.
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.
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
Create an object with the same parameter as the method
Make local variables also instance variables of the object
Create one method called run(), whose body is the same as the body of the original method
In the original method, create a new object and invoke run()
good for simplifying code that doesn’t yield to Extract Method
sometimes the extracted method doesn’t look better as the original code cause of six or more parameters
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