Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I feel the accepted answer was one of the weakest (<a href="https://stackoverflow.com/questions/64333/what-is-the-downside-to-test-driven-development#67184">Disadvantages of Test Driven Development?</a>), and the most up-modded answer smells of someone who might be writing over specified tests.</p> <blockquote> <p>Big time investment: for the simple case you lose about 20% of the actual implementation, but for complicated cases you lose much more.</p> </blockquote> <p>TDD is an investment. I've found that once I was fully into TDD, the time I lost is very very little, and what time I did lose was more than made up when it came to maintence time.</p> <blockquote> <p>For complex cases your test cases are harder to calculate, I'd suggest in cases like that to try and use automatic reference code that will run in parallel in the debug version / test run, instead of the unit test of simplest cases.</p> </blockquote> <p>If your test are becoming very complex, it might be time to review your design. TDD should lead you down the path smaller, less complex units of code working together</p> <blockquote> <p>Sometimes you the design is not clear at the start and evolves as you go along - this will force you to redo your test which will generate a big time lose. I would suggest postponing unit tests in this case until you have some grasp of the design in mind.</p> </blockquote> <p>This is the worst point of them all! TDD should really be "Test Driven <strong>Design</strong>". TDD is about design, not testing. To fully realise the value of benefits of TDD, you have toy <strong>drive</strong> your design from your tests. So you should be <em>redoing</em> your production code to make your tests pass, not the other way round as this point suggests</p> <p>Now the currently most upmodded: <a href="https://stackoverflow.com/questions/64333/what-is-the-downside-to-test-driven-development#64381">Disadvantages of Test Driven Development?</a></p> <blockquote> <p>When you get to the point where you have a large number of tests, changing the system might require re-writing some or all of your tests, depending on which ones got invalidated by the changes. This could turn a relatively quick modification into a very time-consuming one.</p> </blockquote> <p>Like the accepted answers first point, this seems like over specification in the tests and a general lack of understanding of the TDD process. When making changes, start from your test. Change the test for what the new code should do, and make the change. If that change breaks other tests, then your tests are doing what their supposed to do, failing. Unit Tests, for me, are designed to fail, hence why the RED stage is first, and should never be missed.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload