BDD на направляющих - Является сообществом больше позади, Должен иметь или RSpec?
(редактирование - относится к C#; для подхода C++ см. этот ответ )
В основном, нет: Вы не можете. Это было бы огромной поверхностью атаки и не позволяется. Вы могли бы хотеть поместить статический ctor на некоторые типы B, которые гарантируют, что код init выполнен, но это об этом...
6 ответов
Сообщество rails поддерживает как RSpec, так и Shoulda. Это зависит от разработчика.
Если вы предпочитаете Shoulda, используйте его.
Если вы предпочитаете RSpec, используйте его;)
Это разные библиотеки с одинаковой целью. Это не значит, что каждый разработчик должен быть за или против. Это означает только то, что вы можете использовать любой из них.
Выбор за вами в зависимости от ваших предпочтений (и других разработчиков, с которыми вы работаете).
Что касается моков и заглушек (а также фейков, двойников и прочего) - когда вы тестируете на уровне юнитов, либо с TDD , либо постфактум, весь точка говорит ему думать, что у него есть нужные вам данные, используя заглушку. И вы пишете тест для реального объекта, чтобы убедиться, что он действительно производит эти данные. Цель состоит в том, чтобы проверить внутреннее поведение тестируемого класса, а не то, что его восходящие соединения работают должным образом. Это на уровне модуля - вы будете протестировать сквозное поведение в ваших интеграционных или функциональных / сюжетных / приемочных тестах (или любой другой разновидности названия теста более высокого уровня, которую вы предпочитаете).
A mock object, на мой взгляд, больше касается нисходящего потока - вы хотите проверить, что тестируемый класс выполнил соответствующий вызов - вы ' Его не беспокоит, что на самом деле что-то происходит, просто то, что правильный метод был вызван с правильными аргументами. Моки действительно хороши для этого. Rspec имеет свою собственную структуру фиксации, но Mocha и FlexMock также широко используются.
Здесь было много дискуссий / объяснений / дебатов / критики по поводу номенклатуры, BTW . Мартин Фаулер (который лучше всех владеет навыками высказывания по этому поводу) написал в блоге основательный пост, чтобы прояснить его , и я думаю, что это имеет смысл. Вот еще одна статья с несколькими примерами .
Кстати, здесь было много дискуссий / объяснений / дебатов / критики по поводу номенклатуры. Мартин Фаулер (который лучше всех владеет навыками высказывания по этому поводу) написал в блоге основательный пост, чтобы прояснить его , и я думаю, что это имеет смысл. Вот еще одна статья с несколькими примерами . Кстати, здесь было много дискуссий / объяснений / дебатов / критики по поводу номенклатуры. Мартин Фаулер (который лучше всех владеет навыками высказывания по этому поводу) написал в блоге основательный пост, чтобы прояснить его , и я думаю, что это имеет смысл. Вот еще одна статья с несколькими примерами .В RSpec можно использовать макросы shoulda. Это определенно менее распространенный, но отличный вариант: http://robots.aughtbot.com/post/159805987/speculating-with-shoulda .
Но, как говорит Радар, в конечном итоге вы должны попробовать их разные библиотеки и решить.
Наблюдатели должны: 758.
Наблюдатели RSpec: 1279.
В конечном счете, вам решать, какой из них вы предпочтете.
Насколько я могу сказать, в виду того что вы упоминаете BDD, кажется, что будет более естественная спичка между огурцом и RSpec. Больше всего в shoulda мне нравится его валидация-макро. Есть два варианта решения этого вопроса в RSpec:
- использовать макрос shoulda в RSpec, отличный вариант, на который отвечали до
- использовать rspec-validations-expectations плагин, маленький и малоизвестный, но который именно это и исправляет (простое тестирование ActiveRecord validations).
Определённо стоит выбрать, какая из библиотек кажется вам наиболее естественной (как выражаются тесты). Для меня, с ранее упомянутыми опциями, было проще отказаться от опции shoulda (по крайней мере, самостоятельно), и я пошёл за rspec и огурцом.
.Я использую сопоставители Shoulda с RSpec. Лучшее из обоих миров: большое сообщество, стоящее за RSpec, быстрая разработка и обширное освещение с помощью сопоставителей Shoulda.