This test is a little ugly, because it is testing the guts of the implementation, not the externally visible behavior of the objects. However, it will drive us to make the changes we need to make....
I think there's a lot to unpack here.
Writing tests that were tightly coupled to the guts of the implementation was something that people did a lot of experimenting with in the early going - how do you "test drive" recursion, for example? One important lesson: tests that overfit their implementations make those implementations harder to change.
(Part of the problem here is that this example is Java circa 2002; generics haven't been added to the language yet, and so designs like Money extends Expression<Money> aren't an option.)
I think "externally visible behavior" is a spelling error - the type of the object, in Java, certainly is externally visible - you can query the type of an object by sending it a message, just like you would for any other query (ex: toString()).
It's not a domain behavior - which is the more important distinction.
I'm somewhat amused by the fact that Beck is reluctant to couple the test to a specific return type, but has no difficulty coupling tests to specific constructors.
On the whole, the overall design strikes me as unsatisfactory; it passes the tests, which ain't nothing, but "remove duplication" has had a rather devastating impact on the design in the simple case - even within these toy examples. It's not clear to me that a good trade has been made.
No comments:
Post a Comment