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

On Wed, Aug 27, 2014 at 8:23 AM, Colin Vipurs [email protected]
[testdrivendevelopment] <[email protected]> wrote:

>
> > This is something I will let evolve as I add more tests.  It seems like
>> the pain your coworker was feeling could be down to not refactoring the
>> test itself.  Instantiating the class under test multiple times in a test
>> is what I would consider to be duplication
>>
>> In some ways you're exactly correct. He could have used a factory method
>> to extract out duplication in the creation code. But at other times no. He
>> would sometimes write 15 tests for a method and then add a new parameter to
>> the method under test resulting in the need to modify 15 tests. I believe
>> he was doing too much iceberg testing -- that is, he was trying to test an
>> "iceberg" through a small whole rather than testing the individual methods.
>> He hadn't yet tied in how SRP and small units improve the overall TDD
>> experience.
>>
>
> Again I would put that down to duplication.  It's extreme, but if I call a
> method from 15 tests I see that as something that should be extracted.
>

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.


>
>> 1) Assuming each test has some setup -- each of those lines in the test
>> needs to be "tested". In other words, we should be able to see a failure
>> indicating that line in the test is necessary. If we have not seen the
>> "failure" it's possible that we have made an error in the setup which
>> increases the likelihood that we'll have to debug the test.
>>
>
> I'm not sure I'm following you here.  Doesn't the failing test diagnostics
> provide this information/guarantee?
>

I responded to another of your e-mails a little bit ago that I think
explains better, but I'll describe it again here.

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.

--Kaleb