rspec против огурца (истории rspec)

<p>когда мне следует использовать спецификации для приложения rails и когда cucumber (прежние rspec-story)? я знаю, как и работать, и активно использовать спецификации, конечно. но все еще странно использовать огурец. мой текущий взгляд на это заключается в том, что удобно использовать cucumber, когда вы реализуете приложение для клиента, и пока не понимаете, как должна работать вся система.</p><p>но что, если я делаю свой собственный проект? большую часть времени я знаю, как взаимодействуют части системы. все, что мне нужно сделать, это написать кучу юнит-тестов. каковы возможные ситуации, когда мне понадобится огурец?</p><p>и, как соответствующий второй вопрос: должен ли я писать спецификации, если я пишу истории о огурцах? разве это не двойное испытание одного и того же?</p>

<p>если вы еще этого не сделали, вы можете обратиться к отличной статье дэна норта: <a href="http://dannorth.net/whats-in-a-story">что в сюжете?</a> в качестве отправной точки.</p><p>у нас есть два основных варианта использования огуречных историй. во-первых, поскольку форма истории очень специфична, она помогает сосредоточить артикуляцию владельцем продукта на функциях, которые он хочет создать. это использование историй в виде "токена для разговора", и было бы полезно, независимо от того, реализовали ли мы истории в коде. во-вторых, когда процесс работает достаточно хорошо, чтобы у нас были полные истории <em> до </em>, мы начинаем писать функцию (скорее идеал, к которому мы стремимся, чем ежедневный реальность), у вас есть четкие критерии принятия, и вы точно знаете, что и сколько нужно построить.</p><p>в нашей работе rails истории cucumber не заменяют модульные тесты rspec. два идут рука об руку. на практике модульные тесты, как правило, стимулируют разработку моделей и контроллеров, а истории, как правило, стимулируют разработку представлений (мы не склонны писать rspec для наших представлений) и обеспечивают хороший тест приложения в целом из точка зрения пользователя.</p><p>если вы работаете в одиночку, коммуникационный аспект может быть вам неинтересен, но интеграционное тестирование, которое вы получаете от cucumber, может быть. если вы используете <a href="http://github.com/brynary/webrat/tree/master">webrat</a> , написание cucumber может быть быстрым и безболезненным для большинства ваших основных функций.</p>

<p>думайте об этом как о цикле:</p><p>напишите свою особенность cucumber, затем при разработке частей для этой функции напишите спецификации, чтобы завершить отдельные компоненты. продолжайте заполнять спецификации до тех пор, пока вы не напишите достаточно функциональности, чтобы функция могла пройти, а затем напишите следующую функцию.</p>

<p>я считаю, что использование cucumber в большинстве случаев является плохой идеей из-за затрат на производительность, которые несет его синтаксис. я много писал на эту тему в <a href="http://www.jackkinsella.ie/2011/09/26/why-bother-with-cucumber-testing.html">зачем беспокоиться о тестах на огурец?</a> </p>

<p>история с cucumber - это скорее описание общей проблемы, которую решает ваше приложение, а не то, как работают отдельные кусочки кода (то есть модульные тесты).</p><p>как описывает аби, это почти список требований, которым должно соответствовать приложение, и он очень полезен для связи с вашим клиентом, а также для непосредственного тестирования.</p>

<p>в настоящее время вы можете использовать rspec с capybara и selenium webdriver и избегать создания и поддержки всех анализаторов истории cucumber. вот что я бы порекомендовал:</p><ol> <li>напиши свою историю</li> <li>используя rspec, я бы создал интеграционный тест, например: spec/integrarations/socks\_rspec.rb</li> <li>затем я бы создал интеграционный тест, включающий новое описание и блок для каждого сценария.</li> <li>затем я реализовал бы минимальную функциональность, необходимую для тестирования интеграции, и, углубляясь назад (в контроллеры, модели и т.д.), я бы применил tdd для контроллеров и моделей.</li> <li>когда вы вернетесь, ваш интеграционный тест должен пройти, и вы сможете продолжить добавлять шаги в интеграционный тест.</li> <li>повторение</li> </ol><p>однако следует отметить, что тесты контроллера и интеграции имеют перекрытие, которое может быть необязательным, поэтому вы должны использовать свое лучшее решение, чтобы не тратить свое время.</p><p>кроме того, как только вы найдете свою канавку, вам будет очень приятно развиваться с использованием bdd, до тех пор не испытывайте чувства вины, если вы не чувствуете, что делаете это идеально и не переоцениваете это. у тебя все получится!</p>

<blockquote> <p>но что, если я делаю свой собственный проект? большую часть времени я знаю, как взаимодействуют части системы. все, что мне нужно сделать, это написать кучу юнит-тестов. каковы возможные ситуации, когда мне понадобится огурец?</p> </blockquote><p>вам все еще нужен огурец. он нужен для документирования того, как вы видите работу системы, и для того, чтобы убедиться, что вы не нарушили функциональность, когда вы что-то меняете.</p><p>другими словами, истории cucumber нужны по тем же причинам, что и для юнит-тестов - они просто работают на более высоком уровне абстракции.</p>