DHH на модульном тестировании: действительно ли RSpec неоправданно сложен?

Question

Я являюсь подписчиком Ruby Inside, так как меня особенно интересует Rails.Вчера создатель Rails Дэвид Хайнемайер Ханссон (David Heinemeier Hansson) в значительной степени сказал, что он просто использует test / unit.Я бы это понял, поскольку это Rails внутренний, но он, похоже, дал твердое мнение.Он считает, что RSpec и Cucumber слишком сложны.

Я бы обычно не обращал особого внимания, но это зависит от того, кто что-то говорит.Я очень уважаю Ханссона, и его мнение заставило меня задуматься.Когда я начинал с Rails, я никогда не изучал тест / модуль.Просто RSpec и Cucumber.

И вот почему я хочу твоего понимания.Вы думаете, что RSpec действительно сложен из-за небольшой добавленной стоимости?Написание теста / блока занимает меньше времени и усилий?

Answer 1

Моя рекомендация будет заключаться в том, что следует использовать либо musta (расширяет Test :: Unit), либо RSpec с Capybara и -no-Cucumber.

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

Огурец, я наконец-то понял, является более громоздким, чем обычно стоит.Вы можете выполнить то, что вам нужно, проще и надежнее с помощью простых интеграционных тестов и Capybara.Помните - Capybara! = Cucumber, и Capybara вполне способна сама по себе.

Стоит хорошо, потому что она просто добавляет удобства в стандартную среду Test :: Unit и, следовательно, намного легче, чемRSpec (технически каждый решает свой набор проблем, но оба они предоставляют возможности вложенного контекста).RSpec имеет то преимущество, что делает утверждения более естественными, а также генерирует более полезные сообщения об ошибках во многих случаях, при этом нет необходимости записывать аргументы сообщений в утверждениях.

Кроме того, помните, что Cucumber на самом деле не требует RSpec,так что если вы хотите продолжать использовать Cucumber, вы можете сделать это просто с помощью Test :: Unit.Выборов предостаточно.

Answer 2

Все дело в семантике. RSpec и Test :: Unit схожи функционально. Лично я всегда предпочитал RSpec, потому что считал более естественным писать тесты с его использованием. Мне также нравится простота написания пользовательских сопоставлений , и предоставленные сопоставления по умолчанию полезны.

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

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

Answer 3

Это вопрос личного вкуса.

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

Я оставляю детали для Test / Unit.(легко, быстро)

Требуется больше времени, чтобы понять:

get :products, :session => @session_id_for_product_banana
assert_select "table" do
  assert_select "td#name", "Banana"
end

вместо

When I go to the banana page
Then I should see "Banana"

Конечно, эти тесты не равны, но кого это волнует? Банан"находится в div или таблице или не имеет нужного html-идентификатора.

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