Definition
A kind of AutomatedTest, though some would say a better name is DeveloperTest
“Unit” casually refers to low-level test cases written in the same language as the production code, which directly access its objects and members.
Under the strict definition, for QA purposes, the failure of a UnitTest implicates only one unit. You know exactly where to search to find the bug.
xUnit protocol
A test automation framework provides all mechanisms needed to run the test logic. It minimizes the effort of writing fully automated tests. The only entry cost is then incurred while learning to use the framework. This cost, in turn, can be reduced if the framework implements a common protocol such as xUnit. [Mesz298]
The term “xUnit protocol” refers to the underlying architecture and conventions of the family of xUnit testing frameworks, which are based on the original SUnit framework written by Kent Beck in 1989.
Although it was originally designed for unit testing, you can write larger test. If the test can be written in the language you are using, xUnit can run it. [Feat48]
It is possible to use xUnit without any further understanding of how the Test Automation Framework operates, but the lack of more extensive knowledge is likely to lead to confusion when building a reusing test fixtures. [Mesz81]. Following an existing sample is a good way to get something working quickly but it doesn’t necessarily help the developer understand what is really going in [mesz374].
The test fixture is everything we need to have in place to exercise the SUT (System Under Test). Typically, it includes at least an instance of the class whose methods we are testing. It may also include other objects on which the SUT depends. [Mesz78]
The xUnit family of unit-testing frameworks consists of several major components. The most visible is the Test Runner which builds the Testcase Objects, collects them into Test Suite Objects, and invokes each of the Test Methods. The other major component is the library of build-in Assertion Methods. [Mesz300]
When we are writing test code, we concentrate on the Test Methods. The Testcase Class is primarily just a place to put the methods. At runtime, the xUnit framework typically creates one instance of the Testcase Class for each Test Method, so each test runs in isolation. [Mesz374], [https://martinfowler.com/bliki/JunitNewInstance.html]
As the test runner creates an object for each test method, why do test case classes have setUp and teadDown? Why can’t we just create the objects we need in the constructor? By placing code in setup, we run it at a time when we can detect and report any problems that might happen during setup. [Feat50]
The Testcase Objects are aggregated into Test Suite Objects, which then can be used to run many tests with a single user action. The Test Runner tells this Composite [GOF] to run its tests and collect the results. To avoid the need for knowing how to call each Test Method, most members of the xUnit family convert each Test Method into a Command [GOF] object with a run method. [Mesz81]
By convention, each Testcase Class acts as a Test Suite Factory. The Test Suite Factory provides a class method called suite that returns a Test Suite Object containing one Testcase Object for each Test Method in the class. In languages that support some form of reflection, the Test Suite Object may be constructed automatically, containing discovered test methods. Other members of the xUnit family require test automaters to implement the suite method themselves. [Mesz82]
Links:
- Catch2
- Qt Test (Qt5) or Qt Test (Qt6)
- Google Test (includes Google Mock)
- Mock’s Aren’t Stubs
Unit test private functions
It is preferable to test through the public interface. If your class X has a lot of code in the private member functions then it might be worth extracting a new class Y which is used by the implementation of class X. This new class Y can then be tested through its public interface, without exposing its use to the clients of class X. (stack overflow, Feathers p138)