It’s common to unit test at the class level. The
Fooclass will have an associated
FooTestsclass. Solitary Unit Tests follow two additional constraints:
- Never cross boundaries
- The Class Under Test should be the only concrete class found in a test.
In the same entry, Bill also defines a boundary as: ”... or even an ordinary class if that class is ‘outside’ the area your [sic] trying to work with or are responsible for”. Bill’s recommendation is a good one, but I find it too vague. Bill’s statement fails to give concrete advice on where to draw the line. My second constraint is a concrete (and admittedly restrictive) version of Bill’s recommendation. The concept of constraining a unit test such that ‘the Class Under Test should be the only concrete class found in a test’ sounds extreme, but it’s actually not that drastic if you assume a few things.
- You’re using a framework that allows you to easily stub most concrete classes
- This constraint does not apply to any primitive or class that has a literal (e.g. int, Integer, String, etc)
- You’re using some type of automated refactoring tool.
Solitary Unit Test can be defined as:
Solitary Unit Testing is an activity by which methods of a class or functions of a namespace are tested to determine if they are fit for use. The tests used to determine if a class or namespace is functional should isolate the class or namespace under test by stubbing all collaboration with additional classes and namespaces.