RE: Three Law of TDD - to strictly follow, or not?

"'Donaldson, John' [email protected] [testdrivendevelopment]" <[email protected]> Thu, 28 Aug 2014 14:38:04 +0000
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <716D07F3CBA94244A0922E7A99837C3A245A8A5C@G5W2731.americas.hpqcorp.net>
Kaleb,

If you insist (as an earlier poster did) that you first write an assert, then you would avoid this “compilation only” worry (as long as your assert is non-trivial).

John D.

From: [email protected] [mailto:[email protected]]
Sent: 28 August 2014 16:27
To: [email protected]
Subject: Re: [TDD] Three Law of TDD - to strictly follow, or not?





On Tue, Aug 26, 2014 at 12:33 PM, Michal Svoboda [email protected]<mailto:[email protected]> [testdrivendevelopment] <[email protected]<mailto:[email protected]>> wrote:
> Do you consider, "an incomplete but green test is at best misleading
> and at worst wrong"?
A test is only wrong in case you have never seen it fail. All other
tests are complete and functional. As for misleading, that depends how
good a story the test tells. Tests can lie or drift apart from reality.
Usually that is more likely when the test uses mocks.

I think you've just described my biggest concern with writing the entire test up front. When the entire test is written up front (for a new class at least) the test will fail, because a failure to compile is considered a failure. The problem that I have with the approach is that when it "passes", does it pass for the right reason? Or, do we have unnecessary test code? or production code? Did the test ever fail for the expected reason, or did it fail only in the form of a compilation failure?

--Kaleb