Here are a few items I try to respect every time I write unit tests.

  • My test class is testing one and only one class
  • My methods are testing one and only one method at a time
  • My variables and methods names are explicit
  • My test cases are easy to read by human
  • My tests are also testing expected exception with @Test(expected=MyException.class)
  • My tests don’t need access to database
  • My tests don’t need access to network resources
  • My tests respect the usual clean code standards (length of lines, cyclomatic complexity,…)
  • My tests control side effects, limit values (max, min) and null variables (even if it throws an exception)
  • My tests can be run any time on any place without needing configuration
  • My tests are concrete (ex. dates are hardwired, not computed every time, strings too…)
  • My tests use mock to simulate/stub complex class structure or methods
I’m pretty sure there are more.  Any idea ?

Be Sociable, Share!

15 Responses to “Good Unit Test CheckList”

  1. I’d add one more (that is a consequence of your checklist) :
    – My tests are lightning fast !

  2. Yes, a good one ! If you want your tests to be launched often, you’d better make them fast.

  3. I would add:

    • my tests are through, 100% coverage.
    • my tests check all likely method inputs
  4. Thanks Ivan. That’s true. Sometimes 100% coverage is not possible, but it should be the goal.

  5. Personnally, instead of using the “@Test(expected=MyException.class)” to test my exception, i prefer using the @Rule and ExpectedException to test the exception and the message. Check out these 2 links to see what i mean:

    JUnit: Custom ExpectedException rules…rule!

  6. Wow thanks TapaGeur for the great resources. Merci.
    I’ll try this tomorrow since I’ve got more exceptions to test.

  7. I would add:: The test case tests one and only one feature (not method) at a time.

  8. Thanks for the addition Arpana.

  9. The test case should get pass even if is executed in random order.The test case result should not depend on the previous test case. All test cases should be independent.

  10. I dream of a day when you could add to the checklist; “My tests are automatically generated for me by product XXX.”

  11. Regarding the 100% code coverage rule – I do not think it is that important, because it is rather easy to fake your unit tests in order to pass such a constraint. What code coverage is good for is to tell you what has NOT been covered.

  12. >My methods are testing one and only one method at a time
    This is not a good advice. Do not test methods, test features.


  13. Follow also the debate on the dzone page of this article.

  14. [...] Unit Test Check List Are you writing Unit Tests? Then check this list if you are on the correct path. [...]

  15. @Ramon

    Generating tests is no longer fiction, but perhaps Java is a bad candinate for property based testing. See QuickCheck for Haskell/Erlang as an example (I think Scala check is inspired from it)

Leave a Reply

Seo PackagesWhat is seoseo tips