Nail-Tinted Glasses

Hmm. Two questions about statement one.

1: What's a unit? This could be begging the question.

2:How do you deal with a failure in the setup for a unit test? If you're testing the 'database search' unit and the 'database connection' unit would have failed, how does that fit this model? If your unit tests are suitably atomic, then it won't depend on a successful result from 'database connection', but then it can fail with a failure in more than one unit.

A unit (1) can be tested in isolation and (2) is not entirely composed of units. To borrow from another vocabulary, it is an atom. Tested in isolation probably means that the entire domain of the function (that is, the space of the independant variables) can be covered.

2? I rewrite the test. I don't write the test that you have described - but I might write a test that database search unit does the Required Thing[tm] when the database connection unit throws an ImplementedInJavaException. This is normally achieved by substituting an appropriate Mock for real database connection.

In the quote, a "unit" refers to that amount of code that can safely be searched to find that error. But that's not the subject of the (forthcoming) book the quote's from, /Test First User Interfaces/.

That book recognizes that the result of the Refactoring and TDD books is 1~10 edits between test runs. But those books don't say that, they say a bunch of rules and aphorisms that condition programmer behavior, causing that effect as a by-product.

TFUI addresses common behaviors while programming a GUI. When you author hundreds of obvious lines to turn on some effect, you break the 1~10 lines effect in a way that TDD books addressing logic can't constrain. Hence, TFUI turns other books' by-products into rules, and other books' rules into by-products. This might be because GUI programmers think differently, but I wouldn't know. ;-)