StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The effectiveness of TDD is independent of project size. I will practice <a href="http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd" rel="nofollow noreferrer">the three laws of TDD</a> even on the smallest programming exercise. The tests don't take much time to write, and they save an enormous amount of debugging time. They also allow me to refactor the code without fear of breaking anything. </p> <p>TDD is a discipline similar to the discipline of dual-entry-bookkeeping practiced by accountants. It prevents errors in-the-small. Accountants will enter every transaction twice; once as a credit, and once as a debit. If no simple errors were made, then the balance sheet will sum to zero. That zero is a simple spot check that prevents the executives from going to jail. </p> <p>By the same token programmers write unit tests in advance of their code as a simple spot check. In effect, they write each bit of code twice; once as a test, and once as production code. If the tests pass, the two bits of code are in agreement. Neither practice protects against larger and more complex errors, but both practices are nonetheless valuable.</p> <p>The practice of TDD is not really a testing technique, it is a development practice. The word "test" in TDD is more or less a coincidence. As such, TDD is not a replacement for good testing practices, and good QA testers. Indeed, it is a very good idea to have experienced testers write QA test plans independently (and often in advance of) the programmers writing the code (and their unit tests). </p> <p>It is my preference (indeed my passion) that these independent QA tests are also automated using a tool like <a href="http://fitnesse.org/" rel="nofollow noreferrer">FitNesse</a>, <a href="http://seleniumhq.org/" rel="nofollow noreferrer">Selenium</a>, or <a href="http://wtr.rubyforge.org/" rel="nofollow noreferrer">Watir</a>. The tests should be easy to read by business people, easy to execute, and utterly unambiguous. You should be able to run them at a moment's notice, usually many times per day. </p> <p>Every system also needs to be tested manually. However, manual testing should never be rote. A test that can be scripted should be automated. You only want to put humans in the loop when human judgement is needed. Therefore humans should be doing <a href="http://www.satisfice.com/articles/what_is_et.shtml" rel="nofollow noreferrer">exploratory testing</a>, not blindly following test plans. </p> <p>So, the short answer to the question of when to unit-test versus manual test is that there is no "versus". You should write automated unit tests <em>first</em> for the vast majority of the code you write. You should have automated QA acceptance tests written by testers. And you should also practice strategic exploratory manual testing.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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