Тест дизайн в BDD: проверка нескольких сущностей в одном сценарии

общие вопросы
,
#1

Всем доброго времени суток!

Кто и как описывает сценарии в BDD, где нужно проверить несколько сущностей?

Приведу небольшой пример: Допустим у нас есть некий сервис, который собирает статистику по загружаемым CSV файлам. Сервис собирает статистику 3-х типов:

  1. информация о файле (размер, дата создания, имя файла и т.п.)
  2. Информация по формату файла (кодировка, разделитель, символ конца строки и т.п.)
  3. Информация по содержимому файла (кол-во строк и столбцов, статистика по наиболее часто употребляемым словам и т.п.)

Вся эта информация сохраняется например в БД в отдельных таблицах. В голову приходят 3 варианта реализации проверок этих таблиц.

  1. Последовательные проверки: проверяем кажду таблицу в отдельном степе сценария. Плюсы: единый сценарий и более точное и полное описание бизнес логики. Минусы: при неуспешном завершении одного степа, остальные степы игнорируются, следовательно мы имеем не полную картину возможных проблем, если сценарий упал на начальных степах.
  2. Инкапсуляция: здесь я подразумеваю сокрытие (объединение) некоторой бизнес логики в одну сущность, в данном случае, проверка 3х таблиц в едином степе. Плюсы: единый сценарий, возможность добавления Soft Assert проверок, которые дадут возможность увидеть все возможные проблемы в реализации бизнес логики. Минусы: менее точное и не полное описание сценария (в некоторых случаях наверное может даже приводить к разночтениям).
  3. Декомпозиция: разделение проверок на несколько сценариев. Плюсы: сохраняется более или менее полное описание бизнес логики. Минусы: трудность восприятия такого описания функциональности, много однотипных сценариев для одной сущности, более длительное выполнение тестов из-за их количества.

P.S.: Так же хочется заметить, что подход или идеалогия разработки может влиять на вариант выбора реализации. Например первый вариант больше может подойти для agile или TDD, так как время между нахождением дефекта и его локализацией гораздо меньше, чем в каком нибудь waterfall.
P.P.S.: Очень хотелось бы услышать мнение других людей по этому поводу, а возможно и какие-то другие варианты решения подобных ситуаций.

2 лайка
#2

Привет.
Не использую BDD на проекте, но я бы выбрал 1 вариант. Ты описываешь фичу (сбор статистики) у которой проверяешь Сценарии: проверка таблицы с инфо о файле, … инфо о формате, … инфо о содержимом

Не согласен по поводу минусов. Fail шага приведет к Fail’у какого то конкретного сценария, но не проверки остальных сценариев фичи.

Если используешь Cucumber, в нем есть @ContinueNextStepsFor({AssertionError.class})
Вот тут отписание

1 лайк
#3

Вы наверное не правильно меня поняли. Я писал что степы в сценарии игнорируются, а не сами сценарии :slight_smile: Соответственно, если у нас есть например 3 степа проверок в одном сценарии, которые должны быть описаны как часть бизнес логики (бывают такие случаи, возможно мой пример со статистикой не самый лучший), и если один из этих степов падает, то остальные проверки пропускаются. Хочу заметить, что это стандартное поведение пропускать степы если один из них упал.

P.S.: Пользуюсь не Cucumber, но спасибо за ссылку, там я нашел интересную информацию для себя :slight_smile:
P.P.S.: А разве @ContinueNextStepsFor есть в огурце из коробки? На сколько я понял, эта фича есть только в форке от товарища slaout, и issue в стадии Open. В behave, который я использую, эту возможность запилили только в dev версии.

#4

В официальной документации Behave этого еще пока нет, но вдруг кому-то еще пригодится. Реализация Soft Assert на уровне step’ов, работает только в версии behave-1.2.6.dev0:

Feature: Some Feature

    @runner.continue_after_failed_step
    Scenario: Fails in first and third step
        Given first step fails
        When second step passes
        Then third step fails

environment.py:

def before_scenario(context, scenario):
	if "runner.continue_after_failed_step" in scenario.tags:
		scenario.continue_after_failed_step = True

P.S.: ставить behave-1.2.6.dev0 как-то так: pip install git+https://github.com/behave/behave.git

1 лайк
#5

На сколько знаю - вы правы, фича только в форке.

Я сам не пользовался ей, просто встречал описание.