mentis vulgaris
simple thoughts | jason smith
Qualities of Good Unit Tests
Posted by Jason Smith - 02/02/10 at 11:02:08 amSo — you’ve been tasked with insuring your code has unit tests. What does that mean, really?
According to Wikipedia,
unit testing is a software design and development method where the programmer gains confidence that individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class. — http://en.wikipedia.org/wiki/Unit_testing
If you understand the primary beneficiary of unit tests are the developers, then it make sense we should make our unit tests as helpful to developers as we possibly can.
Brett Schuchert and Tim Ottinger, old hands at unit testing, provide some pointers. They describe good unit tests as being “FIRST”:
- Fast
If a developer hesitates to run unit tests because they take a long time to run, the tests won’t be run at all. Unit tests need to be run often (as often as you build – the compiler can only check for correct syntax, the tests insure you got the semantics right), so they need to be cheap and easy to run. One test should take a small fraction of a second. A test suite that takes longer than a few seconds to run is painfully far too slow.
- Isolated
This actually means two things:
- Unit tests should be small enough that the bug is obvious as soon as the test is viewed. A unit test tests one feature of one class.
- Unit tests should never depend on the order the tests are run – if a test breaks because some other test did or did not successfully run before, then the test can no longer be run in isolation
- Repeatable
Tests must be able to be run over and over without any intervention. No hand-loading of a database or editing configuration files. They run whether there is a network or not. Unit tests do not test external systems.
- Self Validating
It must be obvious whether a test passes or fails. We never have to interpret results in a database or a file somewhere. - Timely
Tests are written at the right time. Many argue the right time is immediately before the code being tested is written (I’m usually one of them). Regardless, unit tests should always be written before the tested code is checked into source control.
Michael Feathers (the author of one of the original CppUnit unit testing frameworks) also describes some features that should never be in a unit test. He states a test is not a unit test if:
- It talks to the database (not fast, isolated nor repeatable)
- It communicates across the network (not fast, isolated nor repeatable)
- It touches the file system (not fast, isolated nor repeatable)
- It can’t run at the same time as any of your other unit tests (not isolated or repeatable)
- You have to do special things to your environment (such as editing config files) to run it. (not fast, isolated nor repeatable)
He goes on to say:
Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.
So — are your unit tests FIRST or are they painful?
1 Comment »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds.
Valid XHTML and CSS.
[...] an earlier blog, I discussed the qualities of good unit tests. Primarily, good unit tests are fast, isolate the bugs, repeatable, self-validating and [...]
Pingback by mentis vulgaris » Encapsulating Your Way To Better Unit Tests — March 2, 2010 #