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

>
> I had never thought about calling a single method on the SUT multiple
>> times as duplication. I'll have to spend some more time thinking about that.
>>
> Perhaps I should write this up somewhere.  The usual example I give when
teaching is using Java and moving a method from a static call no a
non-static call.  The test suite now needs to be updated in multiple
places, hence the duplication.

If the entire test is written up front, and a new class is under
> development, that test will fail because of a failure to compile. The
> author could in theory, write lots of production code and then see the test
> "pass" without ever having seen it fail for the expected reasons. I would
> hope that wouldn't happen, but not having seen the full development
> progress or the progression taken it's a concern that I have.
>
>
I get you now.  In my head I see this as two forms of failure, compilation
failure and runtime failure.  I won't even run the test if the compiler is
complaining*.  The key here really is to always see the test fail /for the
right reason/, i.e. the diagnostic output of my assert.  It's good practise
to ensure your diagnostics messages convey all the information you want
them to at this point anyway.

* At least in a language/IDE that offers good support