Unit testing. Example. Boost Unit Test

Test objectives
Testing is the process of examining software in order to identify errors. However, tests can be used for other purposes as well:

as documentation. The tests reflect the expected response of the system to any stimulus. Information recorded in the form of tests can be useful when familiarizing yourself with the device of the program (for example, when a new developer enters the project);
to get acquainted with the project, the programmer can cover the code with tests (so-called “learning tests”). In this case, the developer will formulate his expectations for the code (in the form of test data sets) and check their correctness;
in the case of using third-party libraries, you can run into trouble when updating. Library developers can fix any errors in their code, but this can lead to the fact that our own project will break. One of the possible solutions to the problem is to localize calls to foreign code using the “adapter” design pattern. The adapter is covered by tests and, in the event of a change in third-party code, we quickly find out what exactly broke;
to formalize customer requirements (customer tests, acceptance tests). One of the principles of extreme programming that is currently fashionable is close interaction with the customer. The customer, one way or another, formulates his requirements, which can be expressed in the form of test sets.
Obviously, tests are useful. We would probably really like testing to be launched at our request, and if there are errors, the places and reasons for their occurrence were reported. To achieve this result, it is not enough to come up with test data sets, they need to be formatted accordingly.