Decision tables let you capture combinations of variable values and what outcome, or decision, they lead to. Filling in a table systematically row by row allows us to slow down and reason about individual cases, while ensuring that no cases are left out. Anyone can read a table, and it’s no coincidence that tables are at the heart of many BDD-frameworks. They also translate easily into parameterized tests.
Consider the fictitious example below, which involves a bank granting mortgage loans. The gist is that younger and older clients require an in-depth screening of their financial situation—an investigation. There are many ways to express this in tabular form, and here’s one, which focuses on the boundary values and uses the symbol “—“ as “don’t care.”
| Age | Investigation | Grant loan |
|---|---|---|
| 5 | — | No |
| 17 | — | No |
| 18 | Yes | Yes |
| 18 | No | No |
| 30 | — | Yes |
| 64 | — | Yes |
| 65 | Yes | Yes |
| 65 | No | No |
| 69 | Yes | Yes |
| 70 | — | No |
The keen reader will observe that something fishy is going on. A row seems to be missing! When is the customer old enough to not require an investigation? This is the power of decision tables.
In the formal terminology, “Age” and “Investigation” are the conditions, and “Grant loan” the action. The ages and yes and nos in the investigation column are condition alternatives and, while the yes and nos in the “Grant Loan” column are action entries.