Unit Testing

Unit test is codes that exercise a module (exactly one) and compare the result of it to the expected output. The testing should be done in an isolated environment (controlled conditions) where we’ll check the return value of the component against known values or results from previous runs of the same test (regression testing).

It is #recommended testing the subcomponents first before testing on the main module in which we’ll have a composable testing facility. However, don’t test every public method if they are too simple to test as advised by Fowler.

The tips on writing effective Unit Tests is to think of the boundary conditions under which things might go wrong. It includes possible raised #exception. Concentrate our tests there with a mindset of trying to break the test by specifying possible special cases.

Sometimes, we do write some simple tests while debugging. Don’t toss away them. Formalise those tests into the test suit.

With unit testing in mind, developer will consciously design a program that is highly modular#. Regression Testing# could be implemented to further enhance the validity of the written unit tests to see whether they are adhered to the specified requirements.

Links to this page

Test Driven Development (TDD)

Run all the tests that doesn’t require specialised equipment or environment# (Unit Testing# and Integration Testing#) before checking the code. We should do it often and automatically, which could be done by incorporating the testing facility# into the project build system such as CMake and Makefile. If a full build is necessary, make sure all available tests are running during the process.

Unit Testing# is the foundation of this whole practice. That being said, other testing such as Integration Testing#, Validation and Verification of System Requirements#, Environmental Testing#, Performance Testing#, Usability Testing# and Runtime Diagnostics# should not be underestimated. All test cases should honour its contract where we can check whether the code meet the contract of the contract means what we think it means.
Singleton Pattern

However, Singleton Pattern’s massive drawback is it hides dependencies and increase coupling# as Singleton violates the Single Responsibility Principle (SRP). This makes Unit Testing on the Singleton and the codebase overall hard as there is hardly any circumvention to prevent creating Singleton without affecting the state of the program.
SOLID

We can improve the overall team productivity since the development and testing time for small components are relative short compare to larger counterparts. Smaller module means lesser code, easier to design and simpler to do unit test. Therewith, such component has great usability because it has a specific and well-tested responsibility, plus it doesn’t overlap with other modules.
Regression Testing

Regression Testing is a kind of testing that compares the output of the current tests (usually #202206201320, #202206201330 and #202206201415) with the previous values (from previous ran tests). It is used to find out the disparity or difference, if there is any, of performance, contract, validity etc. between them.
Refactoring

Set up self-checking tests# for the soon-to-be refactored code
Integration Testing

It can be quite similar to what of 202206201320 as the latter also emphasises the importance of testing subcomponents before testing the main module.

#test #exception