Growing Object-Oriented Software, Guided By Tests (chapter 14)

We have now moved on to a new process within the state machine that was mentioned in an earlier chapter. That means it’s time for another end to end test!

Another good use of named value types is discussed - give immutable data names within the code, which will make things easier to reason about later! The authors’ use an enum here to record the state of their auction sniper (are they winning or losing?). It could have just been a boolean, hidden in the code, but they extracted it and named the fields.

Carefully introduce state to objects. In your chosen language, is there a way to test the internal state of an object without breaking encapsulation?

The authors’ introduce another value object at the end of the chapter - this time it is assigned to a variable rather than being extracted. They argue that extracting to an enum would have added complexity for very little gain.

Moral of the story: Know when to break the rules ;)

The authors’ end the chapter by reinforcing that this is how progress is made, one small slice at a time. Any refactorings done now will have the backing of a solid test suite, so should add confidence to the developer working on the system.

As we have designed the code to be loosely coupled (to allow testing), we are finding it easier to add new features.

Remember - the only constant in software development is change!

Again, this was a very Java-heavy chapter, with long sections about a specific Java testing framework. Will make a note that if I ever find myself writing Java, this is the chapter to find out about the philosophy of JMock ;)