开云体育

[TDD] Three Law of TDD - to strictly follow, or not?

Samuel ]slund All Messages By This Member #35582 开云体育 On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [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
Steven Smith All Messages By This Member #35583 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: toggle quoted message Show quoted text ? On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [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
Donaldson, John #35584 开云体育 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: ? On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [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
Tim Ottinger All Messages By This Member #35585 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: toggle quoted message Show quoted text On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [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
Charlie Poole All Messages By This Member #35586 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 tottinge@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote: toggle quoted message Show quoted text ? 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: On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [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
Colin Vipurs All Messages By This Member #35587 I would always do this when leaving for the day, mostly as a way of reminding myself in the morning what I was working on On Wed, Aug 27, 2014 at 2:48 PM, Charlie Poole charliepoole@... [testdrivendevelopment] <testdrivendevelopment@...> wrote: toggle quoted message Show quoted text ? 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 tottinge@... [testdrivendevelopment]" <testdrivendevelopment@...> 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 samuel@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote: On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [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 -- Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head. Something which you, I, and everyone else would call "Tuesday", of course.

Previous Topic Next Topic