Модуль 4 · Урок 14
Test cases, data і trustworthy oracles
Test design відповідає на «як тестувати». Хороший case не залежить від пам’яті автора: він містить traceable purpose, observable preconditions, контрольовані дані, дії та перевірний expected result.
Мінімальна анатомія test case
| Поле | Навіщо |
|---|---|
| ID і condition | Traceability та impact analysis. |
| Title і priority | Однозначна мета та порядок виконання. |
| Preconditions | Спостережуваний стан до першої дії. |
| Data і steps | Контрольований input та відтворювана взаємодія. |
| Expected result / oracle | Критерій рішення, а не «працює правильно». |
Рівень деталізації залежить від ризику, стабільності продукту й досвіду виконавця. Critical або рідкісний сценарій потребує більше конкретики, ніж знайомий low-risk check.
Oracle має бути незалежним
Oracle походить з approved rule, contract, model, calculation, trusted reference system або властивості, яку можна перевірити. Якщо expected result просто повторює поточний UI чи ту саму функцію, що тестується, помилка може підтвердити сама себе.
Test data — окремий керований артефакт
Використовуйте synthetic або masked data, мінімально потрібні атрибути, явну classification, owner, reset і retention. Test має бути незалежним: після cleanup наступний запуск не повинен успадковувати booking, balance або clock попереднього.
Production data не є зручним shortcut
Не копіюйте реальні ПІБ, email, токени чи платіжні реквізити в кейси, скриншоти й ZIP. Для курсу достатньо синтетичних fixtures.
Практика
- Заповніть `test-cases.csv` для трьох conditions.
- Опишіть observable preconditions і cleanup.
- Винесіть fixtures у `test-data-catalog.csv`.
- Замініть vague outcomes на точні state та forbidden side effects.
- Проведіть peer review: чи інша людина отримає те саме рішення.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.