Data-driven, keyword-driven и hybrid описывают, как организованы данные и действия автотестов. Data-driven отделяет варианты входа и ожиданий от общего алгоритма. Keyword-driven описывает шаги через набор команд предметного языка. Hybrid сочетает эти идеи там, где каждая даёт реальную пользу.
Это способы проектирования, а не обязательные поколения фреймворков. Переход от обычного тестового кода к таблицам не делает набор автоматически понятнее. Важно, может ли команда быстро добавить пример, увидеть причину отказа и безопасно изменить поведение, не изучая собственный сложный интерпретатор.
Data-driven: один алгоритм, разные примеры
Подход хорошо работает, когда действия одинаковы, а меняются входы и ожидаемый результат. Например, валидация длины имени принимает пустую строку, один символ, граничную длину и превышение. Каждый набор данных должен иметь отдельную идентичность в отчёте.
Не стоит объединять через параметры сценарии с разными действиями и условиями. Если в тесте появляются ветки «для этой строки сначала авторизоваться, для другой загрузить файл», общность стала искусственной. Лучше несколько ясных проверок, чем одна функция с таблицей скрытого управления.
Самостоятельный пример на Pytest
В учебном контракте имя после удаления внешних пробелов должно содержать от двух до пяти символов включительно. Это правило примера, а не универсальное требование к именам людей. Сохраните код как test_name.py, установите pytest и выполните python -m pytest -v test_name.py.
import pytest
def valid_name(value):
return 2 <= len(value.strip()) <= 5
@pytest.mark.parametrize('value, expected', [
pytest.param('', False, id='empty'),
pytest.param('A', False, id='below-min'),
pytest.param('AB', True, id='min'),
pytest.param('ABCDE', True, id='max'),
pytest.param('ABCDEF', False, id='above-max'),
pytest.param(' AB ', True, id='trimmed'),
])
def test_name_rule(value, expected):
assert valid_name(value) is expectedОжидается шесть независимых результатов. Если изменить верхнюю границу на четыре, случай max должен показать конкретное нарушение. В реальном проекте тест импортирует функцию приложения, а не её копию: копирование реализации в тест не проверит рабочий код.
Откуда брать данные
Небольшой набор обычно легче хранить рядом с тестом. Большие статичные справочники можно вынести в JSON или другой согласованный формат с явной схемой. Содержимое должно проходить review вместе с кодом, особенно когда меняются ожидаемые значения.
Внешняя таблица удобна только при понятном владении и версии. Если её меняют без истории, вчерашний результат невозможно воспроизвести. Секреты и персональные данные не становятся безопаснее от переноса из кода в spreadsheet: тестам нужны синтетические данные и разрешённые credentials окружения.
Если источник содержит больше вариантов, чем требуется для одного запуска, явно задайте правила отбора и сохраняйте выбранные строки. Иначе один и тот же commit будет проверяться на разных незафиксированных условиях, а сравнение результатов потеряет смысл. Полезность данных определяется проверяемой границей или риском, а не размером файла.
Keyword-driven: управляемый язык действий
Keyword-driven задаёт словарь вроде «создать корзину», «применить купон», «проверить итог». Исполнитель связывает ключевое слово с реализацией. Это может помочь специалистам предметной области читать сценарии, если словарь стабилен и соответствует их рабочим понятиям.
Ключевые слова click, type и wait являются техническим языком, а не бизнес-описанием. Таблица из таких команд часто повторяет тестовый код менее выразительным способом. Кроме того, нужно отдельно реализовать валидацию аргументов, диагностику неизвестной команды и совместимость старых сценариев.
Практический пример словаря
Для учебного заказа задайте вход: корзина 10 000 и купон SAVE10. Сценарий состоит из подготовки корзины, применения купона и проверки итога 9 000. Каждый шаг должен принимать типизированные значения и возвращать понятный результат с идентификатором корзины.
При неизвестном купоне ожидается предусмотренная контрактом ошибка и неизменная сумма. Это отдельный сценарий, а не особая ветка общего ключевого слова «успешно применить». Если исполнитель сам вычисляет ожидаемую скидку той же формулой, что приложение, общий дефект может остаться незамеченным.
Hybrid без лишнего слоя
Практичный гибрид может состоять из обычного тестового кода, небольших бизнес-функций и параметризованных данных. Например, одна задача оформления заказа используется с несколькими допустимыми адресами, а ошибки адреса проверяются отдельно на API. Для этого необязательно создавать собственный формат файлов.
Добавлять DSL стоит после появления конкретной потребности. Сначала проверьте, почему существующий язык тестов не подходит читателям и авторам. Если проблема в плохих названиях и слишком длинных функциях, дополнительный интерпретатор обычно не устранит её.
Независимость и диагностика
Каждый пример должен самостоятельно готовить состояние и освобождать ресурсы. Цикл по строкам внутри одного теста хуже параметризации: первое исключение скрывает остальные случаи, а отчёт показывает один результат. Отдельные кейсы позволяют повторить именно проблемный вариант.
Давайте данным содержательные ID: expired-coupon полезнее case-17. При падении показывайте входы, ожидаемое и фактическое значение, но очищайте чувствительную информацию. Для большого словаря полезна ранняя проверка файлов до обращения к приложению: опечатка в keyword не должна обнаруживаться после длинной подготовки.
Типичные ошибки
Часто таблица превращается в программу с условиями, циклами и переменными, но без инструментов обычного языка. Тогда у команды появляется второй runtime, который нужно тестировать и документировать. Другая ошибка — генерировать тысячи комбинаций без модели риска и считать каждую полезным покрытием.
Не смешивайте отсутствие данных с ожидаемым пустым значением. Пустая ячейка, null и пустая строка могут означать разные вещи для API. Зафиксируйте представление и проверяйте его до запуска, чтобы ошибка подготовки не выглядела дефектом продукта.
Как выбрать подход
Используйте data-driven для действительно одинакового алгоритма с разными примерами. Keyword-driven оправдан, если у команды есть устойчивый предметный словарь, понятные авторы и ресурс на поддержку исполнителя. Hybrid должен соединять полезные части, сохраняя простую диагностику.
Успех проверяют на изменении: новый пример добавляется без сложной логики, отказ указывает на конкретное правило, данные версионируются. Хороший framework уменьшает усилия команды и сохраняет смысл проверок; он не обязан иметь максимум архитектурных слоёв.