Начальный · Глава 1 / 18
Превращаем обещание в проверяемый договор
После главы: Отделить факт, ожидание и предположение до написания автоматизации.
В этой главе
Пользовательская фраза содержит несколько правил
Магазин обещает выдать купленную книгу владельцу заказа. В этой фразе спрятаны разные условия: кто считается владельцем, какое событие подтверждает оплату, какая редакция выдаётся и что происходит после возврата. Если сразу написать один успешный тест, эти различия исчезнут в подготовительных действиях. Начните с коротких правил, каждое из которых можно опровергнуть конкретным наблюдением. Например, неоплаченный заказ не создаёт право, чужой пользователь не получает байты, повтор подтверждения не создаёт второй эффект.
Для учебника выберем локальную модель магазина с количеством от одного до двадцати, ценой в целых копейках и условной доставкой. За оплаченный заказ выдаётся доступ к учебным байтам книги. Такая комбинация нужна для разбора арифметики и прав; она не описывает готовый коммерческий продукт. Реальных платежей, банковского протокола, регистрации, HTTP и браузерного интерфейса в итоговом стенде нет. Входные идентификаторы пользователей задаёт сам тест, поэтому проверка авторизации модели не является проверкой настоящей аутентификации.
Три части сценария не следует смешивать
Подготовка создаёт известные данные и условия. Действие вызывает проверяемый путь. Ожидание наблюдает обещанный результат. Для отрицательного доступа подготовка создаёт оплаченный заказ пользователя A, действие просит файл от имени B, ожидание фиксирует отказ без содержимого. Если право создаётся прямой вставкой в базу, такой тест проверяет чтение права, но не путь его выдачи. Это допустимо для узкой проверки, если рядом есть сценарий, проходящий через обработку подтверждения оплаты.
Полезно подписывать уровень рядом с названием. Модульный тест расчёта знает только функцию и числа. Интеграционный тест использует настоящую локальную SQLite. Сквозной тест в рамках модели проходит создание заказа, подтверждение и выдачу байтов, но всё ещё не включает сеть. Термин «сквозной» всегда требует указания границ системы. Иначе один разработчик поймёт под ним цепочку функций, а другой — браузер, платёжную песочницу и файловое хранилище; оба будут говорить о разных доказательствах.
Неоднозначность превращается в решение
Рассмотрим повторное событие с тем же идентификатором, но другой суммой. Можно молча считать его дублем, можно заменить старые данные, можно отказать. Наш договор выбирает отказ, потому что повторный ключ не должен позволять менять содержание уже обработанного события. Тест фиксирует именно это решение. Если правило не согласовано, зелёный результат покажет только совпадение с мнением автора теста. Поэтому спорные границы следует разрешать на примерах прежде, чем превращать их в большой набор автоматических проверок.
У каждого правила есть область применимости. Утверждение «повтор не создаёт второй доступ» относится к одному заказу и смысловому эффекту. Оно не означает, что база содержит только одну строку событий вообще: провайдер может прислать разные события одного платежа. Утверждение «возврат запрещает скачивание» в модели означает новые обращения к методу выдачи. Уже полученные читателем байты невозможно стереть этим методом. Хороший договор не обещает действие, которого архитектура в принципе не выполняет.
Связь с риском делает набор осмысленным
Для каждого сценария запишите, какую ошибку он обнаруживает. Тест чужого владельца ловит пропущенную проверку принадлежности. Тест точной суммы ловит доверие к произвольному уведомлению. Тест повтора ловит дублирование эффекта. Затем укажите, какой близкий риск остаётся: подделка сеанса, неверная подпись провайдера или повреждение файла могут не входить в этот уровень. Такой список помогает расширять набор по новым причинам, а не добавлять десятки похожих успешных покупок ради общего количества тестов.
В конце главы у вас должна появиться маленькая таблица правил и свидетельств, а не обещание полного качества. В дальнейшем каждая новая глава добавит механизм проверки одной границы: данные, состояние, зависимость, транзакция, время или конкуренция. Сохраняйте эту связь при изменении проекта. Когда правило доставки меняется, ищите связанные граничные ожидания; когда меняется хранилище, пересматривайте интеграционные предположения. Тестовый набор становится рабочей моделью договора, которая помогает обсуждать изменения и замечать расхождения до выпуска.
Разобранный пример
Маленькая матрица прав
Таблица содержит независимые ожидания для одного права. Это предметная модель с уже известной личностью, не реализация входа в аккаунт.
pythondef allowed(actor, owner, paid):
return actor is not None and actor == owner and paid
cases = [
(None, 'alice', True, False),
('bob', 'alice', True, False),
('alice', 'alice', False, False),
('alice', 'alice', True, True),
]
for actor, owner, paid, expected in cases:
assert allowed(actor, owner, paid) is expectedТеперь самостоятельно
Практика
Правило говорит: возврат отзывает доступ по этому заказу. У пользователя есть второй оплаченный заказ той же книги. Сформулируйте ожидаемый результат скачивания и уточните, какой объект отзывается.
Результат: Два сценария возврата: единственный заказ и несколько независимых прав.
Подсказка
- Различайте право конкретного заказа и доступ пользователя к произведению через любое действующее право.
Решение и проверка
Если право было единственным, после полного возврата новые скачивания запрещены. Если другой оплаченный заказ создаёт отдельное действующее право на ту же книгу, доступ может сохраниться по нему согласно выбранному договору.
Отзывается право возвращённого заказа, а не глобальная запись «человек больше никогда не может читать эту книгу». Проверка должна показать оба заказа и ожидаемое основание доступа. Уже скачанные байты не удаляются ни в одном из сценариев.
Проверьте себя без текста
Зачем указывать границы сквозного теста?
Чтобы цепочку локальных функций не принять за проверку браузера, сети и внешнего провайдера.
Что делать с неоднозначным правилом перед автоматизацией?
Разобрать конкретные примеры и выбрать наблюдаемый результат, иначе тест закрепит неподтверждённое предположение.
Проверить по первоисточникам
Конец образца
Полный том содержит 18 глав, решения, итоговый проект и словарь. Продажи откроются после предметной редактуры и подключения магазина.