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).
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 28 August 2014 16:27 To: testdrivendevelopment@... Subject: Re: [TDD] Three Law of TDD - to strictly follow, or not?
> 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?