Unit testing is the practice of testing different components of a code where the different components can be taken as independent entities that only interact in order to realize full functionality.
Usually when developing embedded code there is code under test and production code. Production code is code that will be released while code under test is code that is being tested, prior to release or probably as an experimental feature that may never see the light of day.
An effect of not testing code is an unpredictable behavior given an unforeseen input by the author. An example of such is a technique called fuzzing where random input is fed to an executable or code until it fails. Such a scenario would then be used to exploit an unforeseen vulnerability. More details in this Chaos Communications congress talk.
So how do you protect against that which you do not know?
Enter Unity. Unity is a C framework that is composed of C macros that checks(asserts) whether a given code under a given stimuli(input), gives an expected output. It is usually a test of code behavior under different scenarios. The code therefore should be deterministic.
Unity is meant for code that is incrementally tested along its development as opposed to the traditional code development cycle where code is tested after development. This ensures code is tested even before it is refactored. Usage of unity is basically composed of 3 parts:
- Test code– Code that is used to test the code under development.
- Test case– Test code that checks result of code execution against the expected behavior.(Example: Input X should give input Y. If not, test failed).
- Test fixture– A set of test cases that does the same as above but under different scenarios. It is grouped under a single entity. (Example: The code should behave this way for inputs X,Y or Z)
A more detailed use case of unity shall be given in a later post.