Ok, so I’m having a little research fling with JavaScript, and I’ve
uncovered something I hadn’t seen before: “spying”. Basically,
inspecting mocks after-the-fact, rather than setting expectations
upfront.
Here are the articles I found:
Does anyone know more about this technique, and its pros and cons vs
expectation-based mocking as used in RSpec mocks?
Does anyone know more about this technique, and its pros and cons vs
expectation-based mocking as used in RSpec mocks?
Thanks for any info
Ashley
Pat has been working on adding the spy pattern to rspec and JoeSniff has
already added it to the rr mocking framework on github I believe. There
have been some recent posts on this mailing list about it. Searching
for spy in this groups past threads should give you some links to learn
more. HTH
Pat has been working on adding the spy pattern to rspec and JoeSniff
has already added it to the rr mocking framework on github I
believe. There have been some recent posts on this mailing list
about it. Searching for spy in this groups past threads should give
you some links to learn more. HTH
Hi Ben
Ah, the original post about this was on my birthday, no wonder I
missed it
Sorry for the I’m-too-damn-lazy-too-search-my-inbox post!
Pat has been working on adding the spy pattern to rspec
I quit once I found not_a_mock [1] which works nicely. My preference
would be to pull spies into RSpec eventually, but I want to use it a bit
more first (and hopefully others will too).
Looks sweet - it will be in my first mock on Monday!
Thinking about it - how do you use multiple mocking frameworks in a
given project?
Is it safe to re-open a Spec::Runner.configure do |config| block at
the top of an individual spec after I’ve loaded spec_helper (which
will have to be configured to use the default rspec mocking that 90%
of the project uses)?
Looks sweet - it will be in my first mock on Monday!
Wow, there’s some serious work gone into that, and I never knew it
existed! Searched my local archives (from March this year) for Pete
Yandell and he hasn’t posted once to promote it.
Gonna see if I can shoe-horn it into my Merb app somehow, now is the
best time to inflict maximum learning pain on myself
So if I want to have a spec suite which uses a combination of mocking
frameworks, is this possible?
Maybe if some of the files include …/not_a_mock_spec_helper and the
others include …/default_spec_helper and then both those files
require some common spec_helper file?
Thinking about it - how do you use multiple mocking frameworks in a given
project?
Is it safe to re-open a Spec::Runner.configure do |config| block at the top
of an individual spec after I’ve loaded spec_helper (which will have to be
configured to use the default rspec mocking that 90% of the project uses)?
Not really. The problem is that examples are stored for evaluation
later, whereas the configuration is evaluated right away.
The reason rspec won’t support using multiple mock frameworks is rspec
mocks and mocha both extend Object (to support mock behaviour on real
objects) and they use the same methods to create instances of mocks.
I think that if we wanted to support multiple mock frameworks, all of
the frameworks would have to offer an explicit mode where you could
extend objects to behave like mocks but would have to do so explicitly
for each object. Flexmock already works this way.
So if I want to have a spec suite which uses a combination of mocking
frameworks, is this possible?
Maybe if some of the files include …/not_a_mock_spec_helper and the others
include …/default_spec_helper and then both those files require some common
spec_helper file?
That could work - but the conflict I described is a process-wide
conflict - so you’d need to run the examples in those dirs w/ separate
rake tasks to really eliminate the conflict.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.