ruthmoogBook Club: "Test Driven Development: By Example" #14
Chapter 14: Change
Two things stood out to me in this chapter. Firstly was the use of a test to explore Java. Instead of looking up how equality works in objects in an Array, we wrote testArrayEquals to quickly find out if it would work for us.
We found that two array objects would not be considered equal if they contain the same contents.
Earlier I had been working on a ray tracer project, and in that case I wanted to change how equals worked (on the class I had written) so I used the @Override keyword to compare that objects are functionally equal, rather than being the same object. We can't do this with Java's Array but for our own classes it's really nice.
Since we didn't want to use Java Arrays, we introduced our own private helper class instead. This doesn't have or need it's own tests, it simply gives us the means to check if two currency/rate key/value pairs are functionally equal:
public boolean equals(Object object) {
Pair pair = (Pair) object;
return from.equals(pair.from) && to.equals(pair.to);
}
And, for now we are using hashCode to return a rubbishy 0...
0 is a terrible hash value
- Kent Beck
public int hashCode() {
return 0;
}
If we don't create this method, our reduce test will fail, and since we don't care about the value right now this lets our tests pass without worrying about how the hashCode is created.
Assured that we will come back to that later, the next step will be tackling the original task on our To Do list!
🔎 View my code-along repo at https://github.com/ruthmoog/test-driven-development-by-example
