Когда использовать BDD, а когда просто юниттесты? - PullRequest
1 голос
/ 06 марта 2020

У меня есть задача написать тесты для будущего Django Каналы + проект DRF, не спрашивайте почему (пока у нас есть только чванская документация). Таким образом, тесты должны проверить пользовательские сценарии использования (например, сценарий, который может быть сложным). Я исследовал это и нашел BDD. Вот вопрос, учитывая, что в нашем проекте позже могут быть и простые юнит-тесты, что я должен использовать, то есть BDD кажется приличным, но я думаю, что это может быть чрезмерно для использования, и может быть, есть способ просто написать юнит-тесты для использования пользователем случай сценарий, и я могу обойтись этим. У кого-нибудь есть опыт с этим? Было бы здорово, если бы вы предоставили статьи и примеры кода.

1 Ответ

1 голос
/ 06 марта 2020

Scenar ios немного отличается от сценариев использования. Вариант использования часто охватывает несколько возможностей. Например, в показанном здесь простом сценарии запуска dry экономка делает несколько вещей при выполнении wa sh:

  • моет каждую загрузку
  • сушит каждую загрузку.
  • сворачивает определенные предметы
  • утюжит некоторые предметы

Все эти go используются для "еженедельного запуска dry" -case.

Сценарий в BDD гораздо более детализирован. Он описывает одну возможность, имеющую место в определенном контексте или наборе контекстов. Например, у вас может быть:

Given the weekly laundry has been washed and dried
And it contains several sheets
And some underpants
When the housekeeper does the folding
Then the sheets should be folded
But the underpants should not.

Как видите, мы пропустили несколько возможностей. Этот сценарий сфокусирован на возможности сворачивания и показывает, как хорошо ведет себя экономка. Стирка и сушка должны быть рассмотрены в отдельном сценарии ios.

Так что в этом разница между сценарием использования и сценарием. Теперь давайте посмотрим на модульный тест.

Когда мы пишем код, мы не пишем все это в одном большом классе или функции. Мы разделили его на маленькие кусочки. Подобно тому, как сценарий описывает пример поведения системы с точки зрения пользователей, модульный тест описывает поведение класса или другого небольшого фрагмента кода. с точки зрения его пользователей - обычно других классов!

Итак, давайте представим, что мы на сайте покупки автомобилей. У нас есть несколько возможностей:

  • Аутентификация
  • Поиск автомобилей
  • Покупка автомобиля
  • Регистрация автомобиля
  • Удаление автомобиль из списка

Каждый из них будет иметь лотов различных классов, составляющих его. Даже поиск автомобиля может включать в себя внешний интерфейс, компонент поиска, базу данных автомобилей, постоянный уровень, веб-сервер и т. Д. c. Для каждого фрагмента кода мы описываем поведение этого кода.

(BDD фактически начинался на этом уровне; с примерами поведения классов - JBehave был призван заменить JUnit. Но JUnit стал лучше, и нам этот бит больше не нужен. Я все еще считаю его полезным для думайте о них как о примерах, а не как о тестах.)

Обычно в моей кодовой базе будут и модульные тесты Scenar ios и ; один набор из них смотрит с точки зрения пользователя / заинтересованного лица на всю систему, а другой - с подробным описанием моих классов.

Сценарий ios помогает мне показать, как ведет себя система и почему она ценна. Модульные тесты помогают мне выбрать хороший дизайн и разделить обязанности. Оба из них предоставляют живую документацию , которая помогает поддерживать систему в удобном для обслуживания и облегчает приход новичков на борт.

Обычно я так программирую:

  • У меня есть приблизительное представление о том, чего я хочу достичь
  • Я говорю с кем-то об этом и записываю какой-то сценарий ios
  • Если мы не совсем знаем, что мы ища, я получу что-то работающее (всплеск)
  • Как только мы лучше поймем, что мы ищем, я автоматизирую сценарий первый
  • Я беру простейший случай и начинаем писать пользовательский интерфейс
  • Когда пользовательскому интерфейсу нужен другой класс для работы, я пишу несколько примеров того, как этот код должен работать (модульные тесты) сначала
  • Затем Я пишу код (или реорганизую его, потому что спайки беспорядочные)
  • Когда этому коду нужен другой класс, я пишу несколько его примеров
  • Если у меня нет нужного кода в любой момент моих юнит-тестов я использую макеты.

G постепенно мы храним сценарий ios и юнит-тесты в разных местах.

Вы можете увидеть некоторые примеры того, как я это сделал здесь . Это игра тетрис со сценарием ios, который автоматизирует всю игру через пользовательский интерфейс, и юнит-тесты более низкого уровня, которые описывают поведение отдельных фигур, таких как сердцебиение, которое отбрасывает фигуры.

Сказав, что - если ваша кодовая база очень проста, вы, вероятно, можете обойтись только сценарием ios или только юнит-тестами; вам может не понадобиться оба. Но если это станет более сложным, подумайте о рефакторинге и добавлении всего, что вам нужно. Можно быть прагматичным c, если его легко изменить.

...