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

A rule of thumb I followed for many years was to leave a failing test when
taking a break.

Charlie
On Aug 27, 2014 6:41 AM, "Tim Ottinger [email protected]
[testdrivendevelopment]" <[email protected]> wrote:

>
>
> Never trust a test you have never seen fall.
>
> Tests can pass for the wrong reasons.
>
> You have to trust then or get rid of them.
>
> That said, there are intermediate steps which are legitimately green on
> your way to completing a more significant goal.
>
> That only leaves a few little procedural questions.
>
> How long does it remain incomplete?
>
> How do you denote that it is incomplete?
>
> How do you website you don't abandon it?
>
> Most of the time you work one test to completion before check-in or taking
> a break so it is a non-issue.
>
> But if you are forced to leave our for a while, these things matter.
> On Aug 27, 2014 3:09 AM, "Samuel Åslund [email protected]
> [testdrivendevelopment]" <[email protected]> wrote:
>
>>
>>
>> On 14/8/26 17:48, Kaleb Pederson [email protected]
>> [testdrivendevelopment] wrote:
>>
>>
>>  Do you consider, "an incomplete but green test is at best misleading
>> and at worst wrong"?
>>
>>
>> You might want to consider the difference between a test during
>> development locally and a test that have been checked in to the common
>> repository.
>>
>> I have been confused by tests with names saying they check something that
>> is not checked, making me spend time searching for problem in the wrong
>> place.
>> On the other hand during TDD it is rather important to know that the test
>> actually fails, like you and others describe. The key as I see it is if the
>> test is committed or not. Mostly the tests confusing me have come from
>> being interupted while they happened to be green and then missing that they
>> was not compete when coming back.
>>
>> Regards,
>> //Samuel
>>
>>
>>   
>