Я настраиваю приложение для рельсов, и я только что закончил создание модульных тестов, и мой друг сказал, что, по-видимому, светильники уже не круты, а люди теперь используют RSpec или shoulda. Мне было интересно, каковы фактические преимущества использования этих других наборов инструментов. Любая информация вообще ценится.
-fREW
RSpec и аналогичные структуры - это инструменты, предназначенные для помощи в разработке, управляемой поведением. Они не просто более красивый способ писать тесты, хотя они и помогают в этом.
Здесь есть много информации о BDD: http://behaviour-driven.org/ И wikipedia: http://en.wikipedia.org/wiki/Behavior_Driven_Development
Здесь слишком много преимуществ, поэтому я рекомендую немного просмотреть этот сайт.
Я лично предпочитаю ToSA для RSpec. Я нахожу, что у Shoulda меньше магического синтаксиса, чем RSpec. Моя проблема с RSpec заключается в том, что да, она очень читаема, когда я читаю ее вслух, но когда я доберусь до ее написания, хммммм, я никогда не знаю, как должно быть написано данное утверждение. Прага Дейв объясняет проблему лучше меня. Он также любит Shoulda и имеет несколько примеров.
Здесь есть две разные вещи:
Первое, что нужно использовать для написания тестов/спецификаций. Здесь вы можете выбирать между Test:: Unit, RSpec, Shoulda и т.д. Выбор заключается в том, хотите ли вы делать традиционный TDD (Test:: Unit) или предпочитаете ли вы альтернативные способы мышления о специфическом поведении, защищенном разработчиками, например Дэвид Кемлинский (RSpec и в некоторой степени Shoulda).
Во-вторых, как обрабатывать тестовые данные. Есть Rails-приспособления и альтернативы, сложенные с другими целями, такими как плагин FixtureReplacement. Раньше у Rails 2.0 были значительные и хорошо документированные пробные проблемы. Многие из практических вопросов были исправлены в Rails 2.0. Однако светильники могут привести к непреднамеренной тестовой связи, и некоторые из альтернатив пытаются избежать этого.
RSpec намного эффективнее, потому что гораздо легче читать и писать тесты. Он также очень изящный при использовании mocks и stub - концепции, которая станет чрезвычайно полезной, когда вы начнете использовать их в своих тестах. Попробуйте это в простом тестовом приложении (NON RAILS!), И вы увидите, насколько элегантны ваши спецификации по сравнению с эквивалентным стандартным тестированием.
Посмотрите Josh Susser The Great Test Framework Dance-off для сравнения популярных схем тестирования Ruby.
Если вы создаете большое приложение и не имеете команду, которая действительно хороша в написании развязанного кода, который может быть хорошо протестирован с помощью тестов черного ящика и готов полностью использовать использование/отладки большого количества макетов и заглушек, не спускайтесь по дороге Factory.
Где бы вы ни читали о том, как выглядят удивительные заводы, вы увидите небольшое предостережение о том, как фабрики могут оказаться невозможными в большом приложении, потому что они немного медленнее, чем светильники.
Но "немного медленнее" на самом деле на несколько порядков медленнее.
Фабрики не намного проще кодировать, чем светильники, которые используют метки для идентификаторов, пока вы держите светильники организованными. И в некоторых случаях фабрики сложнее отлаживать.
Только сегодня я конвертировал одиночный Factory в светильники, а время работы тестового файла, которое его использовало, составляло от 65 секунд до 15 секунд, хотя только около 15% тестов в этом тестовом файле используют factory.
Если вы используете minitest, вы можете запускать свои тесты в случайном порядке; это быстро выявит связь данных между тестами. (не уверен, что rspec имеет возможность рандомизировать порядок тестирования)
Test:: Unit подходит для небольших приложений. Но есть много преимуществ для использования тестовых фреймворков, таких как Shoulda или RSpec, e. г. контексты!!
Я не вижу Shoulda и RSpec в or-or-relation. Я использую Shoulda в качестве замены RSpec, когда речь идет о тестировании с одним утверждением. Мне очень нравятся одномазырные модели Shoulda, но в RSpec гораздо проще писать коннекторы. Поэтому я советую использовать различные инструменты тестирования, в которых они лучше всего подходят.
Вы можете использовать тестовую инфраструктуру, такую как Cucumber, которая еще быстрее, чем RSpec.