Easy cases can be exploited for software testing as well as in mathematics. Many instances of this are trivial in the sense that any test case written by a human is likely to be an easy case when compared to the universe of all possible inputs. What I’m interested in here are clever and non-obvious applications of easy cases.

Let’s take the example of an FIR filter. Since these eat up a lot of CPU cycles in some systems, people create fiendishly optimized FIRs in assembly that are not so easy to verify by inspection. Chapter 8 of the ARM System Developer’s Guide has many great examples (code here). An FIR filter implementation can be tested using the following easy cases:

Feed the filter an impulse signal (…,0,0,0,1,0,0,0,…) and it should output its coefficients in order.

Feed the filter a step signal (…,0,0,0,1,1,1,…) and its output should settle to the sum of its coefficients.

Feed the filter a sine wave and its output should be a sine wave with the expected amplitude given the filter’s design.

Can you write an FIR that is wrong, but that passes these tests? Sure, but these will weed out a lot of wrong implementations. I learned about these tests here. In general, a lot of codes, particularly mathy ones, have these easy cases that can and should be exploited for simple sanity checks.