Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Re: [TDD] Three Law of TDD - to strictly follow, or not?
> This is something I will let evolve as I add more tests. ?It seems like the pain your coworker was feeling could be down to not refactoring the test itself. ?Instantiating the class under test multiple times in a test is what I would consider to be duplication
? In some ways you're exactly correct. He could have used a factory method to extract out duplication in the creation code. But at other times no. He would sometimes write 15 tests for a method and then add a new parameter to the method under test resulting in the need to modify 15 tests. I believe he was doing too much iceberg testing -- that is, he was trying to test an "iceberg" through a small whole rather than testing the individual methods. He hadn't yet tied in how SRP and small units improve the overall TDD experience.
> You said "I disagree with the comment because it allows multiple unnecessary lines of code to be written and doesn't provide a progression that guarantees that all production code is effectively "tested"/covered.". ?I'd like to ask why you think this? ?Each of my tests are small and cover essentially at most one path through the code.
I'll answer that in parts:
1) Assuming each test has some setup -- each of those lines in the test needs to be "tested". In other words, we should be able to see a failure indicating that line in the test is necessary. If we have not seen the "failure" it's possible that we have made an error in the setup which increases the likelihood that we'll have to debug the test.
2) When we write the whole test without having supported it with the necessary production code, the production code, though testable, will not have had the same opportunity to evolve as it would have had it been co-developed with the tests. To put this another way and refer to J.B. Rainsberger's Queueing Theory post, we've lost the feedback loop between each line in the test and the production code. IMO, when we write the entirety of the test before writing any production code we're more likely to mentally create a design and go with it rather than letting it evolve fluidly.
3) When we don't co-develop the production code with the tests, we've also elongated the time between having a passing unit test and the corresponding implementation which again increases the likelihood that we'll need to debug something or attempt a jump that's too big.
Thank you for your response and questions Colin. Overall, I feel pretty much the same way. Much of what I do is gut feel. Sometimes I will indeed write a whole test before writing the production code, but at other times I'll follow the three laws of TDD to the letter.
My hope was that by asking these questions and eliciting feedback I could move from tacit knowledge to explicit knowledge and thereby be better at TDD and better able to help others.
--Kaleb On Tue, Aug 26, 2014 at 10:04 AM, Colin Vipurs zodiaczx6@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
|
to navigate to use esc to dismiss