Насмешка с rspec и мокко вместе

Для набора тестов, который уже использует мокко для насмешек, можно ли написать новые тесты с насмешкой rspec? возможно, включите это до (: все) и верните его обратно в мокко после (: все)

Я попытался изменить конфигурацию Spec::Runner во время выполнения, и это, похоже, не сработало с насмешкой.


person Samer Buna    schedule 26.10.2010    source источник
comment
Я бы перефразировал ваш вопрос: rspec mocking кажется конфликтующим с мокко. как мне использовать оба в проекте?, и, возможно, направить его людям rspec в IRC, проблемам github и т. д.   -  person Andy Atkinson    schedule 07.11.2010
comment
Укажите, какую версию rspec вы используете.   -  person bobbywilson0    schedule 28.01.2011


Ответы (2)


Я опубликовал новую жемчужину для этого. Вы можете найти более подробную информацию здесь -> http://github.com/endeepak/rspec-multi-mock

person Deepak N    schedule 28.01.2011
comment
огромное спасибо за это :) Используя его прямо сейчас, чтобы перейти с Mocha на RSpec. - person Thibaut Barrère; 27.11.2011
comment
Я рад, что это служит цели :) - person Deepak N; 27.11.2011

Похоже, что гем RSpec Multi Mock от Deepak решает эту проблему.

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

Лично я вполне доволен встроенными средствами насмешек RSpec и обычно не нахожу нужды в Mocha в своих собственных проектах. Но некоторые из моих сверстников предпочитают Mocha, и я действительно не знаю о каких-либо ограничениях Mocha по сравнению с насмешкой vanilla RSpec, поэтому я бы рекомендовал придерживаться Mocha, если это то, что приложение уже использует. Несмотря на то, что я знаю, что его поддержка «any_instance» некоторыми считается запахом кода, иногда она оказывается очень удобной. :)

person Mirko Froehlich    schedule 29.01.2011
comment
Я полностью согласен с тобой. Как я уже упоминал на странице github, этот драгоценный камень, вероятно, следует использовать, когда вы переключаетесь с одной платформы на другую, и у вас недостаточно времени, чтобы преобразовать все варианты использования. Или когда что-то, что вам нужно, недоступно в текущем насмешливом фреймворк. Или бывают случаи, когда вы объединяете два проекта, и они используют разные фреймворки. Конечная цель должна состоять в том, чтобы использовать единую структуру и избегать путаницы. - person Deepak N; 30.01.2011