Test::Unit sequencing

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)

Hmmm … GUIs cannot be unit tested. Testing can be automated, yes,
but they can’t be unit tested. One of the projects is an RSS
library; the components can’t really be unit tested, but the results
can be tested and verified against a large body of work. The other
project is a PDF library (analagous to a GUI), where the only valid
test is the whole result.

Yes, some of the basic components can be tested (and I’m doing so
with the primitives), but especially with the PDF library, the only
useful test is to open the result in a PDF reader.

-austin
– Austin Ziegler, austin@halostatue.ca on 2003.05.16 at 14:39:19

···

On Sat, 17 May 2003 03:29:56 +0900, Anders Bengtsson wrote:

Austin Ziegler wrote:

There are bits that can be tested unit-wise, but they’re smaller
than you might imagine. Neither of these things can be cleanly
unit tested.
Yes they can, it’s just that no-one has found out how yet. :wink:

I’ve repeatedly been surprised when people have invented ways of
unit testing things that seemed hard or impossible to test.

Hi,

I’ve repeatedly been surprised when people have invented ways of
unit testing things that seemed hard or impossible to test.

Hmmm … GUIs cannot be unit tested. Testing can be automated, yes,
but they can’t be unit tested.

GUI libraries themselves could be developed test-first. (I’ve done
just a teensy one in Ruby, but, I don’t see any reason why I couldn’t
keep adding more features and widgets to it, test-first, the way I’ve
done the basic stuff I have so far.)

For web pages & a mailing list w/ people describing how they unit-
test their code using other people’s GUI libraries, there’s
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Regards,

Bill

···

From: “Austin Ziegler” austin@halostatue.ca

On Sat, 17 May 2003 03:29:56 +0900, Anders Bengtsson wrote: