Here are a few items I try to respect every time I write unit tests. It’s a solid and good unit test checklist. At least good for most of my code 🙂
Edit: a more extended and detailed list I wrote for DZone.
- 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
Maybe you’ve already done a great deal by appointing a Test Supervisor that checks every aspect of the finished product. That’s terrific. Congratulations.
But there are still bugs ? Your team is telling you that this little change you asked took the all system down ? How comes ?
For more details about unit tests, see my series: Test Culture Episode 1. The 101 Unit Testing Guide For Busy Managers.
I’m pretty sure there are more point to this unit test checklist. Any idea ?
I’d add one more (that is a consequence of your checklist) :
– My tests are lightning fast !
Yes, a good one ! If you want your tests to be launched often, you’d better make them fast.
I would add:
Thanks Ivan. That’s true. Sometimes 100% coverage is not possible, but it should be the goal.
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:
ExpectedException
JUnit: Custom ExpectedException rules…rule!
Wow thanks TapaGeur for the great resources. Merci.
I’ll try this tomorrow since I’ve got more exceptions to test.
I would add:: The test case tests one and only one feature (not method) at a time.
Thanks for the addition Arpana.
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.
I dream of a day when you could add to the checklist; “My tests are automatically generated for me by product XXX.”
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.
>My methods are testing one and only one method at a time
This is not a good advice. Do not test methods, test features.
—
Cheers,
Tomek
Follow also the debate on the dzone page of this article.
@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)