Во-первых, примечание к терминологии: термин интеграционный тест является немного расплывчатым в сообществе TDD. В зависимости от того, пришли вы из Java или Rails (с Test :: Unit), вы можете понять это по-разному. В Rails (с Test :: Unit) интеграционные тесты - это тесты, которые проверяют ваш полный стек, в то время как функциональные тесты будут тестировать ваш контроллер. Большинство людей в сообществе Java (по крайней мере, по моим наблюдениям) подумают, что все наоборот. Лично я предпочитаю называть сквозные тесты приемочные тесты , а тесты, которые затрагивают несколько уровней системы (но не все) - интеграционные тесты . В целом, это в значительной степени зависит от культуры, в которой вы находитесь.
Что касается Cucumber и Steak - оба являются фреймворками, которые допускают стиль разработки, известный как разработка на основе поведения (или BDD для краткости). Дело в том, что у вас есть два уровня тестов:
- Сквозные тесты , которые проверяют ваш полный стек - они имитируют браузер, проходят через ваши контроллеры и попадают в базу данных. Огурец и стейк подходят к этой нише.
- Модульные тесты , которые тестируют небольшую часть функциональности в изоляции (обычно один класс, насмехаясь над своими сотрудниками). Вот где подходит RSpec.
В BDD вы начинаете с неудачного сквозного теста (с любовью называемого «верхней передачей»), а затем начинаете реализовывать функциональную проверку сначала с RSpec («нижней передачей»), пока не получите сквозное прохождение теста. Таким образом, сквозной тест управляет вашими модульными тестами, которые, в свою очередь, определяют вашу реализацию. Основным преимуществом является предотвращение ползучести области - вы не заканчиваете тем, что не реализуете видимую пользователю функциональность, которая вам не нужна (поскольку вы не пишете для нее сквозной тест).
Если вы хотите получить больше информации об этом, я слышал, что статья * Википедии по развитию поведения на удивление хороша. Также в книге RSpec.
Итак, и Cucumber, и Steak - это фреймворки, которые позволяют вам писать тесты на «верхней передаче». Разница в стиле - у Cucumber есть свои тесты на естественном языке. Это имеет несколько преимуществ.
- Тесты доступны для чтения деловым людям - хотя вы не можете ожидать, что непрограммисты напишут их, они отлично справляются с задачей, сообщая о том, что вы собираетесь делать. Вы можете написать функцию (сначала тест на огурец) и показать ее клиенту, чтобы узнать, действительно ли это то, чего он хочет. Я нашел это очень полезным.
- Функции огурца лучше информируют о намерениях - поскольку вы можете использовать всю мощь английского языка (или любого другого), вы можете общаться почему эта функция актуальна и как пользователи достигают своей цели на уровне, которого Руби не позволит вам.
- Cucumber помогает обнаружить вездесущий язык - домен содержит множество терминов, которые распространяются в разговорах с клиентами. Cucumber позволяет вам обнаруживать и захватывать их, прежде чем приступить к реализации функции. И все это тест-драйв.
- Функции огурца несколько более высокого уровня , что делает функции (но не определения шагов) более независимыми от интерфейса. Таким образом, если интерфейс нужно изменить, вам не придется переделывать функции.
Недостатки в том, что немного сложнее научиться правильно его применять и что вам нужно написать немного больше (как функции, так и определения шагов). Я обнаружил, что второе действительно не проблема, если вы выполняете это некоторое время, поскольку вы получаете множество повторяющихся шагов, которые позволяют быстрее писать следующие функции.
Стейк, с другой стороны, проще, и это Руби. Вы теряете все преимущества использования английского языка, но вы можете писать меньше, и он будет выполняться быстрее (немного).
В нижней строке вы используете и то, и другое для написания сквозных тестов, определяющих разработку.