I know this is wrought with exceptions, but a very crude rule of
thumb is that if your code is not easily testable, it’s probably
poorly designed, too tightly coupled, not cohesive enough, too
big, etc.; in other words, due for a re-think.I would strongly disagree with this.
Really? I would agree that it is difficult to add unit tests to an
existing design (I have plenty of examples of that!). But if you are
doing a design in a test-first manner (using TDD), I find it difficult
to imagine something that would not yield itself to good unit test
coverage.
The counter example is always GUI code, but I’ve found that even in the
few projects I’ve done requiring a lot of GUI work, a significant
portion is still unit testable. The GUI work becomse a thin layer on
top of the business logic … a much thinner layer than I would have
imagined before doing TDD.
There are some things that
aren’t really able to be broken into clean units for testing. Two of
the projects I’m working on right now are difficult to unit test.
Both of them are involved with creating and manipulating documents
that are intended to be dealt with by other programs. In general,
the documents have to be completely correct, or they aren’t valid at
all.
Fascinating! But I’m still not sure I understand /why/ unit tests are
hard. Could you elaborate on this. Perhaps even give a mini-example.
Thanks.
···
On Fri, 2003-05-16 at 13:49, Austin Ziegler wrote:
On Sat, 17 May 2003 00:27:33 +0900, Michael Campbell wrote:
–
– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich
“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)