Таблица решений
Классы и границы разбирают поля по отдельности. Но поведение часто зависит от сочетания условий: скидка положена, если клиент постоянный и сумма больше тысячи, а промокод действует не для всех тарифов. Для таких случаев есть таблица решений.
| Постоянный клиент | Сумма > 1000 | Промокод | Что ожидаем |
|---|---|---|---|
| да | да | нет | скидка 10 % |
| да | нет | нет | без скидки |
| нет | да | нет | без скидки |
| да | да | да | скидка 10 %, промокод не суммируется |
Смысл таблицы не в красоте, а в том, что она делает видимыми пропущенные строки. Три условия «да/нет» дают восемь сочетаний; выписав их подряд, вы сразу замечаете, что про два из них в требовании не сказано ничего, — и это вопрос к аналитику, а не догадка.
Строится она в три шага: выписать условия, выписать возможные результаты, перебрать сочетания. Дальше часть строк схлопывается: если при отсутствии постоянного статуса результат один и тот же независимо от суммы, две строки заменяются одной с пометкой «неважно».
Переходы состояний
Вторая техника — переходы состояний. Она нужна там, где объект живёт во времени: заказ, заявка, договор, аккаунт. Состояние определяет, что можно делать дальше.
| Что проверяем | Пример |
|---|---|
| разрешённый переход работает | новый → оплачен |
| запрещённый переход не работает | отправлен → отменён |
| действие недоступно в неподходящем состоянии | кнопка «Оплатить» у оплаченного заказа |
| возврат в прошлое состояние | оплачен → новый |
Интереснее всего вторая и четвёртая строки. Разрешённые переходы обычно работают — их проверял и разработчик. Ломается на запрещённых: кнопку спрятали в интерфейсе, а сам переход остался возможным, и он случается при повторном нажатии, при возврате назад в браузере или при прямом обращении к серверу.
Отсюда правило: «кнопки нет» не означает «сделать нельзя». Интерфейс прячет действие, а запрещает его сервер — и проверять надо именно запрет, а не его отображение. Урок про API покажет, как это делают напрямую.
Попарное сочетание
Третья техника — про то, что делать, когда условий много. Если у вас три браузера, три роли и три тарифа, полный перебор это двадцать семь прогонов. Попарное сочетание сокращает их до девяти, и потеря при этом невелика.
| Подход | Сколько наборов | Что покрыто |
|---|---|---|
| полный перебор | 27 | все тройки условий |
| попарное сочетание | 9 | все пары условий |
| по одному значению | 3 | почти ничего |
Основание у техники опытное, а не математическое: подавляющее большинство дефектов вылезает при сочетании двух условий, а не трёх и не пяти. Ошибка «в Safari у администратора ломается вёрстка» — это пара. Ошибка, для которой нужно совпадение трёх условий сразу, встречается редко.
Составлять такие наборы руками долго, и обычно это делает готовый расчёт. Важнее уметь объяснить, что покрыто и что нет: после попарного набора вы честно говорите, что тройные сочетания не проверялись, — и если известно, что в тарифе «Х» у администраторов в Safari уже были беды, эту тройку добавляют отдельно.
И общее правило трёх уроков про выбор: техника не отменяет знания предмета. Она превращает знание в набор проверок и позволяет объяснить выбор, но откуда берутся классы, состояния и условия, техника не знает — это вы.