3 ms·
Writing N or 1 tests N times, depending on how many times I have to rewrite the "unit" for some soft idea of completeness. After the red/green 1 case, it necess
by Supermancho 4y ago
Writing N or 1 tests N times, depending on how many times I have to rewrite the "unit" for some soft idea of completeness. After the red/green 1 case, it necessarily has to expand to N cases as the unit is rewritten to handle the additional cases imagined (boundary, incorrect inputs, exceptions, etc). Now I see that I could have created optimizations in the method and rewrite it again and leverage the existing red/green.
Everyone understands the idea, it's just a massive time sink for no more benefit than a test-after methodology provides.
- fsdghrth3 4y agoSee my other comment below. I don't recommend doing it all the time specifically because with experience you can often skip a lot of the rgr loop. > Everyone understands the idea, it's just a massive time sink for no more benefit than a test-after methodology provides. This is not something I agree with. In my experience, when TDD is used you come up with solutions to problems that are better than what you'd come up with otherwise and it generally takes much less time overall. Writing tests after ensures your code is testable. Writing your tests first ensures you only have to write your code once to get it under test. Again, you don't always need TDD and applying it when you don't need it will likely be a net time sink with little benefit.