search

psyho / bogus

Fake library for Ruby
Other
359 stars 14 forks source link

Any way to make transition from vanilla RSpec easier? #30

Open marten opened 11 years ago

marten commented 11 years ago

If you add Bogus, you lose RSpec's double, and the syntax for stub changes. Is there any way of incrementally adding Bogus to an existing codebase?

We're on RSpec 2.14 with no deprecation warnings, so all our test doubles are instantiated with double() (stub/mock are deprecated), but we do have a bunch of object.stub(method: result). This means that (for us) Bogus' stub(object).method { result } should not conflict as long as we can keep object.stub working as in rspec_mocks.

wrozka commented 11 years ago

Hi, I've copied a little bit of rspec-mocks api on top of bogus in this gist. Check if it covers your use cases. It is tested and uses only public api, however it is still a hack, so I would use it only during the transition phase. :)

The double from the gist can create both named and anonymous fakes. Keep in mind that when you use anonymous fakes you loose all the safety benefits.

psyho commented 11 years ago

We should probably consider making this mapping available as a part of Bogus.

marten commented 11 years ago

Maybe an optional require 'bogus/rspec-mocks-compatibility' that the user does if it want it? That file might even raise if the loaded RSpec is known to be incompatible (alternatively: not known to be compatible).

The gist didn't seem to work, but I haven't had the time to track down why yet. Hopefully tomorrow. But thanks for your efforts, really appreciate it!

wrozka commented 11 years ago

What was the problem with the gist? I tested it on rspec 2.14.1 and bogus 0.1.3.

ootoovak commented 10 years ago

@wrozka I agree with @marten and @psyho's suggestion. I think it would help adoption as people would be more confident that the compatibility layer is kept up to date with the Bogus code and that it has some sort of test coverage with out having to come here to find the Gist and find out which version it has been tested against.

I know I have a large project that I would like to port over to Bogus eventually. Knowing I could trust the compatibility layer to stay in sync with Bogus while I make the transition would make me more confident in starting this.

I'm sure it is volunteer work to keep it all up to date so I can understand not wanting to commit to that but I just wanted to give you a use case for having it in the Gem rather than in a separate Gist. Great work so far!