Модуль 3 · Урок 10
Decision tables для business rules
Коли outcome залежить від комбінації умов, список happy/negative cases легко пропускає rule. Decision table робить logic, infeasible combinations і coverage явними до виконання тестів.
Анатомія decision table
Conditions та actions утворюють rows; кожна column — окрема decision rule з унікальною комбінацією conditions і очікуваними actions. Limited-entry table використовує T/F; extended-entry може містити partitions, ranges або discrete values.
| R1 | R2 | R3 | R4 | |
|---|---|---|---|---|
| Member active | T | T | T | F |
| Inventory available | T | T | F | – |
| Payment authorized | T | F | – | – |
| Create booking | X | |||
| Outcome | Confirmed | Declined | Sold out | Membership required |
«–» і infeasible — не те саме
Full table покриває всі combinations. Її можна скоротити, вилучивши infeasible columns або об’єднавши rules, де condition справді irrelevant. Не мінімізуйте table так, щоб зник critical outcome.
Coverage і контроль side effects
Coverage items — feasible rule columns. 100% означає виконати кожну feasible column. Oracle має перевіряти не лише message: booking, inventory reservation, payment capture, audit event і rollback. Для багатьох conditions кількість combinations росте експоненційно, тому ризик-орієнтований scope має бути явним.
Одна умова — не один test
Decision-table testing перевіряє комбінації. Три окремі tests «member», «inventory», «payment» не доводять, що їхня спільна rule реалізована правильно.
Практика
- Завершіть `decision-table.csv` для BookFlow.
- Позначте feasible, infeasible та irrelevant values із поясненням.
- Створіть test для кожної feasible column.
- Додайте oracles для state, inventory, payment і user message.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.