Приходилось ли работать с таблицами в Cucumber?

Что проверяют

Отличаете ли вы два разных механизма Gherkin, которые оба выглядят как таблица, и не превращаете ли feature-файл в выгрузку данных. Заодно смотрят, понимаете ли вы, зачем в проекте вообще нужен BDD.

Как отвечать

Назовите оба механизма и разницу между ними.

• Examples у Scenario Outline: каждая строка это отдельный запуск сценария, подстановка идёт по угловым скобкам. В отчёте получается N сценариев, падение видно построчно, перезапуск тоже построчный.
• Data Table внутри шага: таблица приходит в шаг одним аргументом типа DataTable. Сценарий один, данных внутри много.

Дальше покажите, что делаете с таблицей в коде. В Cucumber для JVM это asMaps(), asLists(), asList(Type), а для своих типов регистрируется преобразователь через @DataTableType, чтобы шаг принимал список объектов, а не сырые строки:

@When("я заполняю анкету:")
public void fillForm(List<Map<String, String>> rows) {
    rows.forEach(form::fill);
}

Хорошая практика: держать в таблице только то, что важно для смысла шага, остальное задавать значениями по умолчанию в коде. Ожидаемый результат делать колонкой, если он различается между строками. Уникальные значения вроде почты генерировать в шаге, а не прибивать гвоздями в feature.

Где спотыкаются

Смешивают механизмы без причины: делают Scenario Outline, а внутри шага ещё таблицу вида «поле, значение» с теми же подстановками. Читать это невозможно, а параметризация уже есть в Examples.

Оставляют один ожидаемый результат на все строки. Классический ляп: в примерах есть и валидная почта, и заведомо битая, а проверка у обеих «вижу сообщение об успехе». Такой сценарий останется зелёным при полностью сломанной валидации.

Раздувают Examples до десятков строк и получают медленный прогон через весь интерфейс. Перебор данных дешевле гонять на уровне API или юнит-тестов, а в feature оставить два-три показательных случая.