I'm working on a project in Ruby on Rails. We have a controller action that uses a module within a gem. This gem isn't finished yet and it isn't on the file system.
I was told to mock the module in order to test the controller. Is there a way to test this without the actual gem? Would mocking the 'require' calls work?
We are currently using Mocha for Mocking and Stubbing.
There is a way to mock the imports in python. Maybe there is a similar answer to mocking the requires in ruby.
How to mock an import
Or please let me know what would be the best way to handle this.
Update: The person who told me to mock it, suggested adding a stub file, but that would require adding test code to the controller and I don't want to do that.
Update 2: The controller uses methods declared in the Module.
If you are writing tests to mock the method calls, they would fail. For example,
controller.should_receive(:method_in_non_existent_module).with(args) #=> errors
In a correct Red->Green TDD scenario , this is alright because the next step would be to require the gem/file, include the module and add the method call in the controller and make the test pass. But you'll not be able to make the tests pass since you can't require the file because it doesn't exist yet.
May be the developer who asked you to mock the method meant to do so not in your tests, but in your actual code. For example, he's writing a gem 'dongle-jokes' which has a method that gets the most popular dongle joke from the most recent tech conference. He doesn't want the gem to be a blocker for you to finish the controller and the views so he asks you to use a dummy interface that spits out a dummy response.
Write the tests that fail
Add a file lib/dongle-jokes.rb
Add the following to that file.
module DongleJokes
def joke
"Dongle jokes aren't funny!"
end
end
Require the file and include the module, use the method in the controller.
The test should pass now. You can remove lib/dongle-jokes.rb when you start using the actual gem.
If you're working in Rails you shouldn't need to add a require to the controller anyway, as when you add the gem to your gemfile it will be required automatically on Rails startup.
What your colleague most likely meant was that you should stub the module itself. Are you using rspec for your tests? If so you should be able to use stub_const. Let's say the module is called Payments. You can then write test code like the following:
before do
stub_const("Payments", stub)
Payments.stub(process: "payments successful")
end
Related
I'm experimenting, and I'm trying to launch dummy Sinatra application from RSpec and kill it when the spec is finished. Something like:
# spec/some_spec.rb
before(:all)
# launch sinatra dummy app
end
after (:all)
# kill sinatra dummy app
end
it 'should return list of whatever' do
expect(JSON.parse(make_request('0.0.0.0:4567/test.json')))
.to include('whatever')
end
I could use system("ruby test/dummy/dummy_app.rb"), but how can I kill that process only? Does anyone know how I can launch the Sinatra inside a test (or from another ruby script)? I know about WebMocks, but I want to see if I can manage to make my test work this way.
Look under RSpec on "Testing Sinatra with Rack::Test". I'd suggest you use that code as boilerplate to get started.
Just add this to your describe block:
def app
Sinatra::Application
end
I would suggest you read up RSpec.
Since you want to test an external system, by the looks of your comment, instead of system "curl whatewer.com", you can use Net::HTTP to make requests and then test against the response.
Have a look at "Testing an external API using RSpec's request specs".
As I'm writing request specs to ensure the features won't be broken I decided to rather write separate Cucumber features. The nice thing is that I can use Capybara, and thanks to Selenium Web Drive, I can launch a server before I run my tests.
So, I created a dummy Sinatra application (that will represent the external service to which the actual code I'm testing is doing requests (including a nasty system('curl whatever.com')).
All I have to do is stub out the methods passed to curl to use Capybara.current_session.server.host and Capybara.current_session.server.port.
Once I'm done with my re-factoring all I have to do is remove the Capybara server variables, and Selenium web drive from the cucumber/capybara configuration.
Tests after a brief change will be still working and will be valid.
Update
In the end I wrote it all with RSpec request tests, as doing it in Cucumber was little bit time consuming and I already spend too much time on this.
I mark these kind of request tests with RSpec tag and Before I lunch these I manually lunch simple Sinatra/Grape dummy API application to which the request are made. (Then I run RSpec tests with this tag)
So basically I end up with specs for functionality that uses net/http that uses WebMock and don't need a server, and request tests for which I need to run the server before I run the specs. So the original question remains, how to lunch a server before tests start
After I cover all the functionality I'm gonig to rewrite the curl to net/http however I'm going to keep those requests specs as I discovered they are nice idea when it comes to crazy API scenarios (like testing https + diggested authentication)
I'm currently converting a whole bunch of acceptance tests from php into ruby and many of the tests use specific scenarios to test certain conditions. We use #dataProvider a lot and my google foo can't find any information if this functionality exists in the test-unit gem.
As a work around I'm manually calling a supporting method to give me the required values to test against and putting the test scenarios in var.each{} loops. It's not elegant but it works. I'd still prefer to use the dataProvider route if it's available though.
Your Google foo is probably very good, however in Ruby something similar is called a fixture.
Fixtures in Ruby Unit Tests
I have a MiniTest suite. I'm using the basic Minitest::Unit::TestCase, not specs. I have setup and teardown methods defined in my TestCase subclass. They work perfectly when I run a test file like so: ruby test/whatever_test.rb. But when I run rake test, setup and teardown are not called. The relevant portion of my Rakefile is:
require 'rake/testtask'
Rake::TestTask.new do |t|
t.test_files = FileList['test/*_test.rb']
t.verbose = true
end
Why wouldn't the setup and teardown be run when Rake::TestTask is used?
I'd paste the test case code into here, but there's quite a lot of it. I'll certainly paste in some subset of it, if there's a particular section you'd like to see.
I'm running Minitest 4.3.2 on Ruby 1.9.3-p194.
The problem was that another test case was overwriting the setup and teardown methods. I had accidentally given two test cases the same class name, which is why the overwriting happened. Naturally, this error didn't happen when I ran a single test case, which explains the difference in behavior when using Rake.
In my case, I was writing tests for socket communication and had added a helper method named send. Since MiniTest uses send internally to call the teardown methods, it was instead calling my own send instead of the method-dispatch.
I'm writing a plugin for Cinch (the IRC bot), and trying to write some RSpec tests for it.
However, I'm trying to get to grips with RSpec, and mocking out the external dependencies of this plugin. I want to test two different things for now - that it says hello to people, and that it keeps track of who it's said hello to.
So I've got a method, say_hello, which takes a Cinch::Message. What's the easiest way to mock this particular class? I'm used to Mockito and Java, so I'm used to making a mock of a particular class.
How can I make a mock of Cinch::Message? In my first test, I want to assert that the reply method is called on that message. In the next one, I just want it to respond like a Cinch::Message would, as I only care about the tracking the class does, not the interaction with the message.
I've only just started out with RSpec, so maybe I'm missing something fundamental. Should I be using a mock? A stub?
Thanks!
First of all documentation would be a nice start point, see: https://www.relishapp.com/rspec/rspec-mocks/v/2-11/docs/message-expectations
..and this is how your test could look:
it 'should call #reply on the message'
message = double('cinch message')
message.should_receive(:reply)
object_under_test.say_hello(message)
end
So I'm trying to figure out a way of stubbing a controller method in rspec for a Sinatra app. The main reason for this is to test the logical flow of the application and to make sure it calls the necessary functions when certain conditions are met. So, in essence, I want to be able to do something like
controller.should_receive(:fancy_method).and_return("This is a string")
What I'm having difficulty doing is accessing the controller instance within the sinatra app. I am able to override the current functions using a class_eval on the sinatra controller class, but I'd love to assert that these functions actually run.
Anyone have any advice?
Thanks.
Dan, I believe what you really want is to just test the controller actions. From a tester's perspective you shouldn't really care about what it actually called but rather for the output, given a specific input and maybe some other special conditions (that is mocking or stubbing other classes) (1).
You can check the official documentation for Sinatra + Rack::Test or this blog post from devver.net.
(1) : If your controller pages are calling some other classes (models, services, etc) you could mock these instead and put expectations on them. For example :
SomeClass.should_receive(:msg).with(:arg).and_return(:special_value)
Some more info for mocking (with RSpec in this exmaple) can be found on the RSpec documentation pages.