корнишон опишите тест или функционал?

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

Самый большой пример, с которым я постоянно сталкиваюсь на работе, заключается в том, что если у вас есть доступ к элементу A, то вы должны иметь доступ к A. У нас может быть 20 различных типов пользователей с доступом к A, поэтому мы выбираем только 1 ( чтобы наш набор тестов не занимал 40 часов). Так что же "лучше"?

A

Scenario: A user with access to item A can access A
Given I am a type 4 user with access to item A
When I try to access A
Then I am granted access to A

or B

Scenario: A user with access to item A can access A
Given I am a user with access to item A
When I try to access A
Then I am granted access to A

Обратите внимание на разницу в данных утверждениях (пользователь типа 4)

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

Итак, A описывает, что делает тест (вход в систему с пользователем типа 4 с доступом к элементу A).

И B описывает функциональность, необходимую для доступа к элементу A (просто пользователь с доступом к элементу A).

Прежде чем вы спросите, как мы определяем, кто имеет доступ к элементу А, это SQL-запрос к базе данных в поисках определенного элемента, связанного с пользователем.


gherkin
person Matt Westlake    schedule 12.03.2013    source источник

Ответы (3)


arrow_upward
8
arrow_downward

Для теста на огурец вы тестируете бизнес-логику - как приемочный тест - а не конкретные детали реализации. Так что вы ДОЛЖНЫ делать второе, а не первое. Спецификации запроса или интеграционные тесты могут быть более привязаны к специфике, если вы хотите запускать тесты для типа X, типа Y и пограничных случаев.

Я думаю, что можно думать об этом — и это не жесткое быстрое правило — как о чем-то вроде:

Модульный тест, чтобы изолировать методы и тестировать одну вещь за раз. Смоделируйте и заглушите все остальное, чтобы изолировать то, что тестируется.

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

Спецификации запросов — иногда в простых приложениях это почти то же самое, что и интеграционные тесты, в других случаях я буду проводить интеграционные тесты для всего, кроме стека запросов, и специально выделять свои спецификации запросов. Мнения будут разными.

Приемочные тесты — это то место, где вы сидите со своим вопросом — когда тесты написаны на простом деловом языке и не содержат деталей технической реализации в определениях функций.

В любом случае, даже если вы проигнорируете мысли об остальной части тестового стека, в конкретном вопросе, который вы задаете, выберите B.

person Richard Jordan    schedule 26.03.2013

arrow_upward
0
arrow_downward

Я бы сказал, что вариант Б лучше. «Пользователь типа 4» звучит как деталь реализации.

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

person andrewtatham    schedule 26.03.2013

arrow_upward
0
arrow_downward

Я бы сказал, что Б лучше. Для «пользователя типа 4» вы можете сделать его частью фона:

Backgound : User is logged in
Given "Type 4 user" is logged in

Используйте заполнитель для пользователя типа 4, поместив его в «», чтобы вы могли повторно использовать определение шага, вошедшего в систему, для другого пользователя, у которого есть доступ к элементу A.

person fancypi    schedule 11.04.2013
comment
Гораздо более естественным подходом было бы описание пользователя: входит администратор или входит новый пользователь. - person Chriseyre2000; 27.08.2013