Re: [TDD] 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
?
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 samuel@... [testdrivendevelopment]" < 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
|
