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 ?
Jean-Baptiste Rieu
Mobile/BackEnd Software Engineer & Scrum Master
Applications should be robust and extremely well designed. Whatever the domain and the medium.

I fight for that with the help of talented people. I want to help you in this mission too.

Fervent supporter of unit testing, constant refactoring, agile approach and good user experience design from scratch. I also believe in the well conceived truly RESTful APIs.

Love to learn through real projects. Invent new ones if necessary.

Also invested in business and culture comparison between France and Korea (my wife’s country).
Currently learning Korean.

저는 프랑스 소프트웨어 엔지니어이며 사업에 관심이 많습니다. 창조성과 팀워크의 개선을 항상 바라고있습니다. 영어를 능숙하게 구사하며 한국어는 배우는 중입니다.

소프트웨어(새로운 Agile 기법이나 단순 폭포수 접근법을 이용한) 개발에 대한 도움이 필요하다면 저에게 알려주세요.

제 부인의 나라인 한국을 사랑합니다. 한국 관련 사업의 기회와 문화를 접하고 싶습니다.

한국이나 프랑스로의 수출을 구상 중이시라면 저에게 알려주세요.
프랑스 문화와 비지니스에 대한 저의 사견을 제공해드릴 수도 있습니다.

* Organizational Specialties : SCRUM, Visual boards, JIRA virtual work, Serious Games and brainstorming sessions, Lean and the Toyota Way
* Dev Specialties: iOS front-end, backend API and server logic (mainly in Java)
Unit Testing, Continuous Integration. Agile Approach.
User Experience and Product Improvement (via A/B testing, analytics and user interviews)
Eclipse RCP, JFreeChart, OpenGL, Data Visualizations.
* Interested in : Startup and entrepreneurial adventures, Big Data Science/Mining, Drone development in urban environment, connected cars, augmented reality for tourism and culture, in flight entertainment, high frequency operations and highly available and scalable architectures in general.

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