Chapter 13: Make It
Previously we'd written some fake code that was returning a value we wanted for our test to pass, instead of using real logic. To remove this fake implementation, we used a test to drive us forward to a real implementation, but, it's a test we don't want to keep.
That's because the test is testing the implementation, solely for the purpose of helping write the code we want.
If you know tests, you know already that we test behaviour not implementation. @quii did a great talk to explain this, using a shape factory as an example;
If we write a test to check the squares made in the square plant, good tests might be that the square has four sides, and all sides are the same length. If the square plant outsources some of it's work to the rectangle plant, we might test that a square is also made of two rectangles. But that's a bad test because, although it passes, if we switch our outsourcing in the future to the triangle plant, our tests will fail. We don't care if the square is made from rectangles or triangles (that's implementation detail): we just care that we get squares from the square plant.
Another thing happening in this chapter is some casting of types and checking with instanceof which then gets refactored out. Beck talks about a limitation in Java:
Bank.reduce(Expression, String)
Expression.reduce(String)
...which he says isn't a problem in languages with keyword parameters. The name of the method in both classes is the same but parameters are different. I'm not familiar with keyword params, is this something anyone here has experience of?
🔎 View my code-along repo at https://github.com/ruthmoog/test-driven-development-by-example
Top comments (0)