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.

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

Each row is simulated independently, with no clock edge between rows. That makes this a tool for combinational circuits: a design containing flip-flops or counters carries state from row to row in ways the table cannot express, and the page warns you when it detects them.