Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h1>Tips:</h1> <h3>Avoid writing procedural code</h3> <p>Tests can be a bear to maintain if they're written against procedural-style code that relies heavily on global state or lies deep in the body of an ugly method. If you're writing code in an OO language, <a href="http://googletesting.blogspot.com/2009/07/how-to-think-about-oo.html" rel="noreferrer">use OO constructs</a> effectively to reduce this.</p> <ul> <li>Avoid global state if at all possible.</li> <li>Avoid statics as they tend to ripple through your codebase and eventually cause things to be static that shouldn't be. They also bloat your test context (see below).</li> <li>Exploit polymorphism effectively to prevent <a href="http://misko.hevery.com/2008/08/14/procedural-language-eliminated-gotos-oo-eliminated-ifs/" rel="noreferrer">excessive ifs and flags</a></li> </ul> <h3>Find what changes, encapsulate it and separate it from what stays the same.</h3> <p>There are choke points in code that change a lot more frequently than other pieces. Do this in your codebase and your tests will become more healthy.</p> <ul> <li>Good encapsulation leads to good, loosely coupled designs.</li> <li>Refactor and modularize.</li> <li>Keep tests small and focused.</li> </ul> <h3>The larger the context surrounding a test, the more difficult it will be to maintain.</h3> <p>Do whatever you can to shrink tests and the surrounding context in which they are executed.</p> <ul> <li>Use composed method refactoring to test smaller chunks of code.</li> <li>Are you using a newer testing framework like TestNG or JUnit4? They allow you to remove duplication in tests by providing you with more fine-grained hooks into the test lifecycle.</li> <li>Investigate using test doubles (mocks, fakes, stubs) to reduce the size of the test context.</li> <li>Investigate the <a href="http://www.natpryce.com/articles/000714.html" rel="noreferrer">Test Data Builder</a> pattern.</li> </ul> <h3>Remove duplication from tests, but make sure they retain focus.</h3> <p>You probably won't be able to remove all duplication, but still try to remove it where it's causing pain. Make sure you don't remove so much duplication that someone can't come in and tell what the test does at a glance. (See Paul Wheaton's <a href="http://www.javaranch.com/journal/200603/EvilUnitTests.html" rel="noreferrer">"Evil Unit Tests"</a> article for an alternative explanation of the same concept.)</p> <ul> <li>No one will want to fix a test if they can't figure out what it's doing.</li> <li>Follow the Arrange, Act, Assert Pattern.</li> <li>Use only one assertion per test.</li> </ul> <h3>Test at the right level to what you're trying to verify.</h3> <p>Think about the complexity involved in a record-and-playback Selenium test and what could change under you versus testing a single method. </p> <ul> <li>Isolate dependencies from one another. </li> <li>Use dependency injection/inversion of control.</li> <li>Use test doubles to initialize an object for testing, and make sure you're testing single units of code in isolation.</li> <li>Make sure you're writing relevant tests <ul> <li>"Spring the Trap" by introducing a bug on purpose and make sure it gets caught by a test.</li> </ul></li> <li>See also: <a href="http://www.infoq.com/presentations/integration-tests-scam" rel="noreferrer">Integration Tests Are A Scam</a></li> </ul> <h3>Know when to use State Based vs Interaction Based Testing</h3> <p>True unit tests need true isolation. Unit tests don't hit a database or open sockets. Stop at mocking these interactions. Verify you talk to your collaborators correctly, not that the proper result from this method call was "42".</p> <h3>Demonstrate Test-Driving Code</h3> <p>It's up for debate whether or not a given team will take to test-driving all code, or writing "tests first" for every line of code. But should they write at least some tests first? Absolutely. There are scenarios in which test-first is undoubtedly the best way to approach a problem.</p> <ul> <li>Try this exercise: <a href="http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/" rel="noreferrer">TDD as if you meant it</a> <a href="http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/" rel="noreferrer">(Another Description)</a></li> <li>See also: <a href="http://agile2003.agilealliance.org/files/P6Paper.pdf" rel="noreferrer">Test Driven Development and the Scientific Method</a></li> </ul> <h1>Resources:</h1> <ul> <li><a href="http://my.safaribooksonline.com/9781932394856" rel="noreferrer"> <em>Test Driven</em> by Lasse Koskela</a></li> <li><a href="http://my.safaribooksonline.com/9780321574442" rel="noreferrer"> <em>Growing OO Software, Guided by Tests</em> by Steve Freeman and Nat Pryce</a></li> <li><a href="http://my.safaribooksonline.com/0131177052" rel="noreferrer"> <em>Working Effectively with Legacy Code</em> by Michael Feathers</a></li> <li><a href="http://specificationbyexample.com/" rel="noreferrer"> <em>Specification By Example</em> by Gojko Adzic</a></li> <li>Blogs to check out: <a href="http://blog.jayfields.com/" rel="noreferrer">Jay Fields</a>, <a href="http://thediscoblog.com/" rel="noreferrer">Andy Glover</a>, <a href="http://www.natpryce.com/" rel="noreferrer">Nat Pryce</a></li> <li>As mentioned in other answers already: <ul> <li>XUnit Patterns</li> <li>Test Smells</li> <li>Google Testing Blog</li> <li>"<a href="http://www.youtube.com/watch?v=acjvKJiOvXw" rel="noreferrer">OO Design for Testability</a>" by Miskov Hevery</li> </ul></li> <li>"<a href="http://www.javaranch.com/journal/200603/EvilUnitTests.html" rel="noreferrer">Evil Unit Tests</a>" by Paul Wheaton</li> <li>"<a href="http://www.infoq.com/presentations/integration-tests-scam" rel="noreferrer">Integration Tests Are A Scam</a>" by J.B. Rainsberger</li> <li>"<a href="https://www.youtube.com/watch?v=7HecgbghFTk" rel="noreferrer">The Economics of Software Design</a>" by J.B. Rainsberger</li> <li>"<a href="http://agile2003.agilealliance.org/files/P6Paper.pdf" rel="noreferrer">Test Driven Development and the Scientific Method</a>" by Rick Mugridge</li> <li>"<a href="http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/" rel="noreferrer">TDD as if you Meant it</a>" exercise originally by Keith Braithwaite, also <a href="http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/" rel="noreferrer">workshopped</a> by Gojko Adzic</li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

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