Unit testing is a method by which individual units of source code are tested. A unit is the smallest testable part of an application. In procedural programming, a unit may be an individual function or procedure. If you’re writing front-end code in React, it may be an individual component.
The implementation of unit testing can vary from being very manual (pencil and paper) to being formalized as a part of build automation.
Unit testing benefits
Since test cases for all functions and methods are written, whenever a change in the overall system causes a fault, the unit that is causing it can quickly be identified and fixed.
Hence, unit testing allows the programmer to refactor code at a later date and make sure the module works correctly after other components are added.
Unit testing can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.
Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain a basic understanding of the unit’s API.
Although many software development environments do not rely solely upon code to document the product in development, using code to assist in documentation has an advantage, since ordinary narrative documentation is more susceptible to drifting from the implementation of the program and will thus become outdated.
When software is developed using a test-driven approach, the unit test may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.
Common pitfall: not separating interface from implementation
Because some classes may have references to other classes, testing a class can frequently spill over into testing another class.
A common example of this is with classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should not usually go outside of its own class boundary, and should especially not cross process/network boundaries because doing so can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, so when test cases fail, it is much less clear which component is causing the failure.
Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the effective net coupling), the independent unit can be more thoroughly tested than may have been previously possible. This results in a higher quality unit that is also more maintainable.
Unit testing by definition only tests the functionality of the units themselves. Therefore, it will not catch integration errors or broader system-level errors (such as functions performed across multiple units, or non-functional test areas, such as performance). Hence, unit testing should be done in conjunction with other software testing activities.
Like all forms of software testing, unit tests can only show the presence of errors; they cannot show the absence of errors.
There are also many problems that cannot easily be tested at all – for example, those that are non-deterministic or involve multiple threads.
Lastly, writing code for a unit test is likely to be at least as buggy as the code it is testing.
Language-level unit testing support
Some programming languages support unit testing directly. Their grammar allows the direct declaration of unit tests without importing a library.
Additionally, the boolean conditions of the unit tests can be expressed in the same syntax as boolean expressions used in non-unit test code, such as what is used for