Andrew Binstock again is right on, but actually hits only the tip of agile’s test-first inadequacies iceberg (“Driving development with functional tests”). While typical tiny test-first unit tests beat traditional test-last-or-never, they indeed are likely to miss important functionality that Binstock’s bigger tests can demonstrate.
However, both methods are subject to significant additional weaknesses that neither realizes. Despite writing the tests first, they are likely the same as tests they’d write after writing the code, because developers envision the code they expect to write and then test that it works as envisioned, not that considering if they’ve written the correct code.
Moreover, the set of tests usually overlooks all sorts of conditions, partly because developers’ orientation mistakenly assumes that one or two tests suffice, and partly because even professional testers seldom have any idea how many test conditions they’re missing. For example, a two-character field has 65,536 possible inputs, which even when distilled easily may represent over 100 equivalence classes, each of which takes separate tests.
Since long before Kent Beck adopted the phrase, my Proactive Testing methodology has included “letting testing drive development” in truly agile, non-busywork ways that help developers avoid many of the defects that, as Binstock points out, are still made with typical test-first techniques.
