Re: [TDD] Three Law of TDD - to strictly follow, or not?
|
I think all the answers have been wise and sensible. But then, I think the answers all come from ¡°Ha¡± or ¡°Ri¡± practitioners, and
I suspect Kaleb was talking to ¡°Shu¡± people.
(If you are wondering what I am talking about, there¡¯s a concise explanation of ¡°ShuHaRi¡± here:
)
?
I¡¯d really like a beginner to try to stick to three rules pretty strictly, with the probably addition of Samuel¡¯s ¡°Commit¡±.
?
John D.
?
toggle quoted message
Show quoted text
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 27 August 2014 14:55
To: testdrivendevelopment@...
Subject: Re: [TDD] Three Law of TDD - to strictly follow, or not?
?
Exactly. You should only commit the test after you've gone through the full Red-Green-Refactor. In fact, assuming you're using DVCS or your own branch, I would go so far as to say that you should always Red-Green-Refactor-Commit. I've written
more on this here:
?
On Wed, Aug 27, 2014 at 4: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
--
Steve Smith
|
