Unit testing and integration testing are ubiquitous for software development and chip design. Unit testing consists of numerous test cases which test various aspects of the unit/device under test. Typically, unit test cases make sure that all required behaviors are performed by the unit under test.

One problem that comes up time and time again is that of unit test cases being broken and yet reporting “everything is working”. On reporting dashboards this shows up as “All green”, while the truth is quite different – one or more test cases are reporting a pass while they should be reporting a fail.

Injecting a Fault

We need a way to test a test case. One way to do that is to inject a fault into the unit under test. This fault must be exactly what the test case is testing for. In other words, the unit under test must be broken on purpose in such a way that the unit test is expected to catch this failure. If the unit test fails to catch the injected fault then we know the unit test is broken.

Fault injection on purpose can be accomplished several ways: a parameter, a generic, an ifdef. Each of these would change the unit under test to behave incorrectly, in such a way that a particular test case is expected to catch the faulty behavior.

Surely, there are more creative ways to inject a fault into the unit/device under test. Leave a comment if you want to share your creative way to inject a fault.

Replace the Unit Under Test

Another way to Test the Tester is to replace the unit under test with a unit test for the tester. The purpose of this unit test would be to test the tester. This method may be simpler to implement in some cases, or some testing infrastructures, as there would be no modifications to the unit under test needed – no need to pollute unit under test code with additional code to test the tester.