Огурец избавляется от необходимости писать модульные тесты?

Ответ 1

Используйте огурец на высоком уровне, чтобы описать, что пользователь должен видеть и делать. Используйте RSpec, Test: Unit, Shoulda и т.д. Для написания модульных тестов. Прямо от лошадиный рот:

Когда вы решите, что хотите добавить новую функцию или исправить ошибку, начните с написания новой функции или сценария, описывающего работу этой функции. Не записывайте код (пока).

...

Это когда вы начинаете писать код. Начните с написания нескольких строк кода, чтобы решить проблему, которую вы получили от Cucumber. Запустите огурец снова. Повторяйте и промойте, пока вы не удовлетворитесь своей особенностью. Когда вы приступите к подробным подробным сведениям, опустите один уровень абстракции и используйте RSpec или любую инфраструктуру тестирования Ruby, чтобы написать некоторые спецификации/тесты для ваших классов.

Огурец предназначен для проверки всего вашего стека вместе, в отличие от "единиц".

Вам нужно решить, где рисовать линию, но многие под капотом, вероятно, не будут покрыты тестом на огурцы. Скажем при регистрации, я заполняю форму, с моим именем, адресом электронной почты, номером телефона и т.д. unit test может проверить, что новый User также создаст новый TelephoneNumber. С точки зрения пользователя им все равно, что он создает новый TelephoneNumber, им важно, что после регистрации они имеют учетную запись и могут видеть их номер телефона.

У меня не слишком много опыта написания тестов на огурцы (пока нет), но я надеюсь, что это немного поможет.

Ответ 2

Когда unit test терпит неудачу (я имею в виду реальный unit test, который тестирует метод изолированно с помощью mocks), он сообщает вам, что проблема с "единицей". Когда приемочный тест терпит неудачу, он сообщает вам, что "функция" имеет проблему, а не там, где проблема находится.

Ответ 3

Когда вы создаете приложение rails, по умолчанию вы получаете функциональные, интернатные и модульные тесты. Огурец является дополнительным тестом, это способ также проверить опыт, который ваш пользователь будет иметь. Когда они нажимают кнопку с надписью "go", они должны видеть "успех", а не 404. Это будет гарантировать, что ничто из вас случайно не испортит пользовательский интерфейс, а сверху вниз ваше приложение работает для наиболее распространенных которые вы можете придумать. Другие тесты предназначены для обеспечения того, чтобы ничто не пошло не так, и что вы проверили модель и метод с помощью микроскопа. Возможно, можно полностью повторить единичные тесты с огурцом, но было бы больно (и сумасшествие было бы медленным, особенно если вы используете селен). Лучшее время для написания тестов - это когда вы разрабатываете код, а самый быстрый и простой способ сделать это - это использовать встроенное тестирование рельсов и, возможно, некоторую дополнительную помощь, такую ​​как shoulda, rspec, также я огромный поклонник factory -girl. Если вы еще не проверили это, у www.railscasts.com есть отличное введение к огурцам, rspec и factory -girl,... Я знаю, что на этот вопрос уже был дан ответ (это нет), но это мой два цента. Кодирование удачи!

Ответ 4

Я много думал/много боролся с этим вопросом, и здесь, где я приехал.

Огурец первый и огурец последний. Огурец обеспечит первичный охват тестированием.

Методы базовой модели, которые выполняют настоящую деловую работу приложения, также должны разрабатываться/покрываться с помощью тестов rspec/unit.

Почему модуль также тестируется?

1) Модульные тесты будут протестировать намного быстрее. 2) Эта основная бизнес-логика может (возможно,) использоваться несколькими способами за пределами текущих представлений (которые проверяет Cucumber). Эти методы должны быть забиты всеми возможными входами и выходами, напрямую вызывающими метод в тесте.

Почему не unit test остальные модели, а также контроллеры и представления?

1) Огурец уже покрыл его один раз. 2) Я обнаружил, что методы view-controller-some-model все работают вместе, чтобы добиться результата (думаю, что все реализовано для входа); поэтому мне нравится их тестировать вместе.

Ответ 5

Я занимаюсь Cucumber/RSpec за последние полгода или около того BDD.

Прежде всего, BDD нелегко войти, он будет чувствовать себя неестественно в начале.

Но как только вы займетесь этим, нет другого способа программирования.

Чтобы ответить на ваш вопрос. Для тестирования Javascript вам понадобится драйвер javascript, который может использоваться Capybara, который используется Cucumber.

capybara-webkit - это то, что сейчас используют все классные дети в настоящее время

Там есть одна важная вещь.

Интеграционные тесты выполняются медленно.

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

Моя тестовая установка, которой я очень доволен:

Охрана для загрузки spork Spork для более быстрых тестов Огурцы для тестирования интеграции capybara-webkit для тестирования javascript RSpec для модульного тестирования

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

Ответ 6

Лично я не думаю, что вы должны прекратить писать модульные тесты. В качестве инструмента приемочного тестирования Cucumber должен заменить ваши функциональные тесты и, если вы пишете, просмотрите тесты.

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

Ответ 7

Из моего опыта, Cucumber и Rspec имеют различную привлекательность. Rspec обращается ко мне с точки зрения разработчика, потому что его легко писать и обеспечивает очень быструю обратную связь, когда что-то ломается. Огурец не привлекает меня как разработчика, потому что он не работает так быстро, как Rspec. Тем не менее, Cucumber обращается ко мне как к бизнес-участнику, поскольку он обеспечивает полный охват целых функций.

Сделайте себе одолжение и продолжайте писать модульные тесты.