In my current Rails 3 app, I'm doing some unit testing to make sure that calls to update S3 are only done under certain situations. I don't want to update S3 during tests, so I'm using Mocha to stub out the behaviour. Is there a way to make sure a function is called using mocha? I've taken a look at Expectations, and unless I'm doing it wrong, it seems I have to do:
object.expects(:function_name).once
However, this does not yield the desired results: This will flag an error if function_name is called twice(which is desired), it will NOT flag an error if it is only called once(as it should), but the problem is it WILL NOT flag an error if the function is called zero times. I need a way to make sure it is called. It seems like mocha should support this, so maybe I'm doing it wrong. Any help would be greatly appreciated.
***** CORRECTION:
Turns out that I was doing it right, except that the mocha_verify method wasn't being called automatically. For anyone who is having a similar problem, check out Ole Morten Amundsen's answer over here: Mocha Mock Carries To Another Test
or just
object.expects(:function_name).twice
alternatively, if it has differnet input you should test that
resultmock = mock
object.expects(:function_name).with(someobject).returns(mock)
resultmock.expects(:something).returns(true)
object.expects(:function_name).with(resultmock)
don't know if this helps, but it should give you a kick start. FYI: 'once' is default. Good luck, do TDD (=test-first) or mocking will be a pain :)
Be sure to load mocha last, so it is really being loaded, as in my answer here:
Mocha Mock Carries To Another Test
Try:
object.expects(:function_name).at_least_once
Have a look at the docs: http://mocha.rubyforge.org/classes/Mocha/Expectation.html#M000042
Related
I'm fairly new to using RSpec, so there's a lot I still don't know. I'm currently working on speccing out a section of functionality which is supposed to run a script when a button is pressed. The script is currently called in a controller, which I don't know if there's a good way to test.
I'm currently using
expect_any_instance_of(ConfigurationsController)
.to receive(:system)
.with('sh bin/resque/kill_resque_workers')
.and_return(true)
in a feature spec and it works, but rubocop is complaining about using expect_any_instance_of and I've been told to only use that method if there was no better way.
Is there any better way to test this? Like is there a way to get the instance of the controller being used, or a better kind of test for this?
A better pattern would be to not inline the system call in your controller in the first place. Instead create a seperate object that knows how to kill your worker processes and call that from your controller. The service object pattern is often used for this. It makes it much easier to stub/spy/mock the dependency and make sure it stops at your application boundry.
It also lets you test the object in isolation. Testing plain old ruby objects is really easy. Testing controllers is not.
module WorkerHandler
def self.kill_all
system 'sh bin/resque/kill_resque_workers'
end
end
# in your test
expect(WorkerHandler).to receive(:kill_all)
If your service object method runs on instances of a class you can use stub_const to stub out the new method so that it returns mocks/spies.
Another more novel solution is dependency injection via Rack middleware. You just write a piece of middleware that injects your object into env. env is the state variable thats passed all the way down the middleware stack to your application. This is how Warden for example works. You can pass env along in your spec when you make the http calls to your controller or use before { session.env('foo.bar', baz) }.
Here's the call I would like to test expectations for:
UserMailer.invoice_paid(user, invoice).deliver_later
Rails 5 ActionMailer behaviour in :test mode seems to return nil on every method of an ApplicationMailer class. This should be fine since I can just stub it like so:
invoice_paid_dbl = double(ActionMailer::MessageDelivery)
allow(UserMailer).to receive(:invoice_paid).and_return(invoice_paid_dbl)
This expectation fails:
expect(UserMailer).to receive(:invoice_paid).once
While this one passes:
expect(invoice_paid_dbl).to receive(:deliver_later).once
Shouldn't that be impossible? I thought maybe the method chain was confusing RSpec, but splitting up the line into this has no effect:
mail = UserMailer.invoice_paid(user, invoice)
mail.deliver_later
Adding .with(any_args) to the stub and expectation also has no effect (since that's the default anyways). The failure is expected: 1 time with any arguments, received: 0 times with any arguments.
Not getting how you have stubbed methods, but think that following will work for you
You are trying to stub chain of methods so need to use stub_chain instead of stub
UserMailer.stub_chain(:invoice_paid, :deliver_later).and_return(:invoice_paid_dbl)
I hope this will work and solve you problem. For more details please check docs
I'll leave the question up in case it helps others, but this was actually the result of a silly mistake. I had expect(UserMailer).to receive(:invoice_paid) earlier in the it block, and it was passing. It was the second expectation of that type which was failing. Oops.
In cucucmber i want to run a step after all the scenarios in a feature are run, can I have an after hook for the entire feature, I currently have after hooks for each scenario.
I know its been a long time, but i havent been a user here for long but,
There is an exit hook that is used like this:
at_exit do
# Add code here
end
This should be placed in your env.rb file or the features/support directory
Here's a great link
It's a bit of a workaround, but you could just have scenarios at the beginning and the end of the feature for setup/teardown. Scenarios are run in the order that they are specified so as long as you have the setup scenario at the top and the teardown at the bottom then it works fine.
I also name the Scenario 'Scenario: feature setup' and 'Scenario: feature teardown' to make it more obvious when outputting the results to a formatter.
You can use a custom formatter, and use the after_feature method.
(I used to have a link with more information, but #katta just pointed out that its no longer available)
Sure, just tag your feature.
After('#mytag') do
#Do your magic here
end
This documentation might help: http://cukes.info/cucumber/api/ruby/latest/Cucumber/RbSupport/RbDsl.html#AfterStep-instance_method
I'm using rspec to test a code that may fail depending on the change of a site structure (the external influence I mentioned). I would like to write an example that involves "should raise an error" but I'm not sure if rspec is the right tool to test code in such situations. Could someone point me in some direction?
Thanks in advance
You could write custom matchers
Something like :
site.should_have_valid_structure
Spec::Matchers.define :have_structure
match do |actual|
actual.structure == Site::VALID_STRUCTURE
end
end
Mock the external influence so you can test it properly (if the external influence is a Web page or other HTTP request, WebMock and VCR are great for this). Your tests should not rely on anything external functioning properly -- or improperly. See http://marnen.github.com/webmock-presentation/webmock.html for an overview I wrote last year.
I'm writing some functional tests for a controller in rails, using mocha to do mocking/stubbing.
Is there a way to prevent the template from being rendered during the test, so that I can test only the code in the controller?
It looks like rspec provides something like this, but I'm not using rspec.
The most obvious solution seems to work:
#controller.expects(:render)
I could have sworn that I tried that last night with no luck. But this morning it works like a charm. I must have overlooked a typo.
It doesn't look like using stub is necessary here. If you want to make sure that a given template is rendered, use assert_template and/or assert_response. You can also assert a state of the response object, either by hand or using helpers like assert_select.
Would render_to_string do what you need?