Keyboard Shortcuts
Likes
Search
[TDD] Three Law of TDD - to strictly follow, or not?
|
Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:
Do you strictly follow the three laws of TDD as literally written?Either approach you described can be justified. Test that just contains one variable is actually complete and says "the object can be constructed this way". Remember there is an implied "this does not fail" even if there are no asserts. In the classic cycle, you would then proceed to write another test, that tells a different story. Then, in the refactor phase, you'd maybe remove the first test. From my experience indeed sometimes you want to go so slow that this is useful. Other times not. In absence of gut feeling, do baby steps. Also, in non-strict typed languages (i.e. javascript) a test that just describes object construction syntax could be useful. Do you consider, "an incomplete but green test is at best misleadingA test is only wrong in case you have never seen it fail. All other tests are complete and functional. As for misleading, that depends how good a story the test tells. Tests can lie or drift apart from reality. Usually that is more likely when the test uses mocks. Michal |
|
On Tue, Aug 26, 2014 at 12:33 PM, Michal Svoboda pht@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
I think you've just described my biggest concern with writing the entire test up front. When the entire test is written up front (for a new class at least) the test will fail, because a failure to compile is considered a failure. The problem that I have with the approach is that when it "passes", does it pass for the right reason? Or, do we have unnecessary test code? or production code? Did the test ever fail for the expected reason, or did it fail only in the form of a compilation failure? --Kaleb |
|
Donaldson, John
开云体育Kaleb, ? If you insist (as an earlier poster did) that you first write an assert, then you would avoid this “compilation only” worry (as long as your assert is non-trivial). ? John D. ? From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 28 August 2014 16:27 To: testdrivendevelopment@... Subject: Re: [TDD] Three Law of TDD - to strictly follow, or not? ?
? On Tue, Aug 26, 2014 at 12:33 PM, Michal Svoboda pht@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
? --Kaleb
|
|
On Thu, Aug 28, 2014 at 8:38 AM, 'Donaldson, John' john.m.donaldson@... [testdrivendevelopment] <testdrivendevelopment@...> wrote: If you insist (as an earlier poster did) that you first write an assert, then you would avoid this “compilation only” worry (as long as your assert is non-trivial). I remember seeing that post but I forgot to respond -- that's a good idea that I've never tried. Done properly that should provide the necessary guarantees. Thanks for re-pointing that out. --Kaleb |
|
Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:
When the entire test is written up front (for a new class at least)Hi Kaleb, I hear what you are saying. But it really goes down to that gut feeling. Sometimes I want to see the whole story first, not just "once upon a time there was an object". It usually depends on what level of certainty I feel over my requirements. The objective is to drive the design with the test, not to just write it first. Even if the test is written in a bigger chunk, you can still add in the code one bit at a time and see the test fail for various reasons until you get (and subsequently fix) the desired one. Cheers, Michal |
|
Michal,
On 8/28/14 12:03 PM, Michal Svoboda pht@... [testdrivendevelopment] wrote: Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:I write acceptance tests all at once. I write unit tests a bit at a time, often starting with the creation of a new object whose definition does not yet exist. In this fashion I work inside-out within the bounds of outside-in.When the entire test is written up front (for a new class at least)Hi Kaleb, Even if the test is written in a bigger chunk, you can still add in theWith effort, you can. But how does that drive the design? - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ---------------------------------------------------------------------- |
|
Starting with acceptance tests is a great idea. So is starting with high level unit tests, mocking the details, and then working your way down. Also, sometimes if I think I know what the essence of the problem is I will start there, or if I'm not even sure how I am going to do it I may just pick something to spike.?
Any of these techniques, or a combination, can be used with a given story. TMTOWTDI On Thursday, August 28, 2014, George Dinwiddie lists@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
|