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 ?
  • http://www.rugeri.fr Etienne Rugeri

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

  • http://jbrieu.info Jean-Baptiste Rieu

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

  • Ivan S Kirkpatrick

    I would add:

    • my tests are through, 100% coverage.
    • my tests check all likely method inputs
  • http://jbrieu.info Jean-Baptiste Rieu

    Thanks Ivan. That’s true. Sometimes 100% coverage is not possible, but it should be the goal.

  • http://www.tapageur.org/ TapaGeuR

    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!

  • http://jbrieu.info Jean-Baptiste Rieu

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

  • http://blog.aparnachaudhary.net/ Aparna Chaudhary

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

  • http://jbrieu.info Jean-Baptiste Rieu

    Thanks for the addition Arpana.

  • Gangadharan G

    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.

  • Ramon J Santiago

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

  • http://www.gravatar.com/avatar/01795b4543b30b3cf29f6a204465c2e3.png Bogdan Marian

    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.

  • http://kaczanowscy.pl/tomek Tomek Kaczanowski

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


  • http://jbrieu.info Jean-Baptiste Rieu

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

  • Pingback: Best Java Testing Articles during Summer 2011 « Only Software matters()

  • http://hatimonline.com Hatim


    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)