Почему огурец считается инструментом тестирования интеграции вместо инструмента тестирования единицы?

Ответ 1

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

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

Только для обновления функция будет содержать следующее:

Как некоторые заинтересованные стороны системы Я хотел бы выполнить действие
Чтобы я мог извлечь из этого выгоду

Given a precondition
When I perform an action
Then something should happen

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

Теперь, используя их для модульных тестов, в лучшем случае окажется неудобно. Прежде всего, ориентация конечных пользователей предполагает более интеграционный подход, поскольку функция ничего не говорит о mocks и UI/логическом разделении. То есть функция вроде следующего просто кажется странной:

Given a that a database mock is configured with the following data
| ID  | Username |
| 0   | igor     |
When call FindAll on User Repository
Then I get the following user back
| ID  | Username |
| 0   | igor     |

Кроме того, поскольку ваш SUT становится меньше (т.е. класс), контекст работы не так важен. Пользовательский репозиторий не заботится о контексте, например. его не интересует, является ли его потребитель обычным пользователем или VIP-пользователем. Простой компонент (который должен быть, после SRP), полностью детерминирован на основе его входов.

Итак, unit test существует, чтобы проверить, что то, что вы написали, является правильным, и тест cucmber заключается в том, чтобы подтвердить, что написанное вами приложение удовлетворяет некоторой более высокой цели, поставив поведение системы в контексте.

Ответ 2

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

Он также вводит целый ряд других проблем. Во-первых, вам нужно связать сценарии Cucumber с набором светильников, так что есть еще один слой абстракции, который заставляет их писать медленнее. Во-вторых, английский труднее реорганизовать, чем код, даже с динамическими языками, такими как Ruby (разница еще более выражена в вариантах С# и Java, таких как JBehave, SpecFlow, Cuke4Nuke и Cuke4Duke). Труднее сказать, все еще используются этапы, и сложнее поддерживать сценарии. Также сложнее управлять состоянием между различными этапами.

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

Из-за накладных расходов на огурцы и потому, что мы не получаем преимуществ от преимуществ, которые Cucumber обеспечивает взамен своих накладных расходов, RSpec лучше подходит для поведения на уровне единицы. (Это также относится к JUnit, NUnit и т.д.)

Если вам не хватает "Given, When, Then" из Cucumber, попробуйте добавить их в качестве комментариев. Это хорошо работает для меня.

Ответ 3

Общая идея заключается в том, что тесты на огурцы написаны на более высоком уровне, чем традиционные модульные тесты. Например, если вы unit test конкретный модуль, вы сосредоточены на тестировании только функций модулей в изоляции от остальной системы. Интерфейс в другие части системы обычно должен быть представлен макетными объектами.

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

Тестирование модулей = Инженер-механик тестирует свой новый двигатель в лабораторном режиме, установленном на жгуте.

Испытание огурца = тест-драйв, помещающий его на дорожку для вращения.

Ответ 4

Модульные тесты должны изолировать отдельный код unit. Обычная гранулярность - это метод (или несколько взаимодействующих методов) в классе.

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

Тесты на огурцы, в частности, сосредоточены на полном стеке приложений, поскольку они реализуют приложение, моделируя реального пользователя в интерфейсе и во всех слоях приложения, от пользовательского интерфейса до задних служб (базы данных, файловую систему, сети и т.д.) используются и используются.

Нижняя строка:

a unit test проверяет, что конкретный фрагмент кода соответствует его контракту с остальным миром...

В то время как тест огурца проверяет взаимодействие нескольких фрагментов кода (вертикальный фрагмент, который могут сказать некоторые люди), с дополнительной красотой, которую сам тест читает, как простой английский.

Ответ 5

Согласно Aslak Hellesøy, Cucumber не является инструментом тестирования, а скорее инструментом совместной работы (для BDD). Недавно он опубликовал об этом очевидном заблуждении:

https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html

Тем не менее, есть много тестов, написанных ниже уровня принятия, который упадет на уровне тестовой интеграции. Т.е.,

Given a user at 123 Evergreen Terrace
When I lookup their name
Then I get Homer Simpson

вместо

Given an address
When I lookup a name
Then the home owner name is displayed

Это не помогает, что cukes.info показывает как императивный пример (а не декларативный).

Тесты на огурцы работают медленнее по сравнению с Rspec или Test:: Unit или MiniTest. У них много накладных расходов (на загрузку среды может потребоваться несколько минут, включая все классы объектов страницы, анализ файлов функций и фактическое выполнение тестов). Выполнение только единичных тестов Cucumber будет быстрее, чем запуск интеграционных эквивалентных тестов, но не так быстро, как запуск чего-то более легкого веса, такого как три вышеупомянутых.

(Я отвечаю на этот старый вопрос, так как он был одним из первых попаданий, которые я получил при поиске альтернатив Cucumber для тестирования интеграции)