Test cases

Writing test cases for a circuit

A truth table tells you what a circuit does. A test case tells you whether that is what you wanted. You declare the input combinations you care about together with the outputs you expect, run them, and get a verdict per row instead of a table you still have to read.

This matters as soon as a design outgrows exhaustive testing. Above ten inputs a full table is thousands of rows, but the cases that actually matter — boundary conditions, carry propagation, the one encoding that broke last time — are usually a handful. Writing them down turns a design review into something repeatable: change the circuit, rerun, see instantly whether you broke a case that used to pass.

• Column names are matched to the labels you gave your INPUT and OUTPUT elements.
• An x in an output column means "do not care" — useful when only part of the result is defined for that input.
• A failing cell shows the value the circuit produced next to the value you expected, so you see the discrepancy without re-simulating by hand.
• A C in an input column is a clock pulse: the signal goes 0, then 1, then 0, and the outputs are checked once the circuit has settled. That is how you test flip-flops, registers and counters.

# half adder
A B | S C
0 0 | 0 0
0 1 | 1 0
1 0 | 1 0
1 1 | 0 1

Without a C, each row is simulated on its own, so a table describes a combinational circuit. With one, the rows become a sequence: they run top to bottom from power-up (every register at 0), state carries from row to row, and an x in an input column keeps its last value. A table for a 4-bit counter is then just a column of C with the count you expect after each pulse.