Follow Along as I Stumble on the Path to Learning RoR

Posts tagged “rspec

Useful Rails Testing Gems

Here’s a list of Rails gems that have been helpful in testing for me:

RSpec Rails – for using the RSpec framework for testing

Capybara – for testing the app like a visitor would interact with the web app

Factory Girl Rails – makes it easy to create instances of models and associations

Shoulda Matchers – makes it easier to test and verify things with methods that use easy to understand language

Database Cleaner – to help keep your test environment from having a bunch of extra and redundant data

Warden – since I use Devise, this makes it easy to sign in in my Capybara tests without having to go to the login screen each time (and then to the pages I really want to test)

Guard – allows me to automatically test the code and specs that I change so I don’t need to remember to manually kick off a test each time a change is made

Launchy – useful with Capybara tests when I can’t figure out why a test is failing.  Launchy launches a browser so you can see the contents of the page.’save_and_open_page’ line to your spec when you want to do this.

 

Advertisements

Testing Braintree on Ruby on Rails

I’m using Braintree with a Ruby on Rails app via the braintree_ruby gem.

I needed to test responses in some of my tests.  Here’s how I was able to simulate some transactions.

I created a transaction, such as this:

result = Braintree::Transaction.sale( :amount => “100.00”, :payment_method_nonce => nonce_from_the_client )

To simulate different types of transactions, I changed nonce_from_the_client to the different options here putting the string in quotation marks.

To test a declined transaction, I used a nonce for a declined transaction and adjusted the amount to one that would fail, such as this:

result = Braintree::Transaction.sale( :amount => “2000.00”, :payment_method_nonce => “fake-processor-declined-visa-nonce” )

 


Stubbing current_user in Testing

Stubbing current_user is easy for testing:

@user = FactoryGirl.create(:user)

controller.stub!(:current_user).and_return(@user)


Testing Email with RSpec

I ran into two types of errors when testing if emails triggered in the code with RSpec.

The first issue was that RSpec was not correctly determining if an email was triggered.  I knew the email was getting triggered correctly, but my test was failing.  The reason was that I was putting the should matcher too late.

Mailer.should_receive(:email_name)

I was putting this after calling the method I was testing (i.e. post :create) like I do with all of my other matchers.  However, with Mailer.should_receive, it should go before the call.

The second issue I had was that I was getting the error message:

Undefined method ‘deliver’ for nil:NilClass

For this, I had to stub out the response, like so:

Mailer.should_receive(:email_name).and_return(double(“Mailer”, :deliver => true))


Checking Field Values When Posting in RSpec Controller

I was having trouble figuring out how to check that field values posted in RSpec Controller specs.  In models, I will usually do something like:

@foo.reload.name.should eq “bar”

However, that doesn’t work in Controller specs – it doesn’t recognize reload.

In that case, all you have to do is:

assigns[:foo].name.should eq “bar”


HTTP_REFERER Error in RSpec

If you find that you get this error in RSpec:

No HTTP_REFERER was set in the request to this action, so redirect_to :back could not be called successfully. If this is a test, make sure to specify request.env["HTTP_REFERER"].

Then you have to specify this in your spec:

request.env[“HTTP_REFERER”] = “where_i_came_from”

based on this answer in StackOverflow (it of course doesn’t necessarily have to equal “where_i_came_from”).  This can happen if you redirect :back in your code.


Checking Instance Variable in RSpec After Update

I was having trouble getting one of my RSpecs to pass which I knew should be passing.  The problem was that when I did the check, the instance variable still held the old value.

For example:

it “should update status to in progress” do

  issue = FactoryGirl.create(:issue, status: “new”)

  Issue.method_to_update_status

  issue.status.should eq “in progress”

end

I knew  that the status was updating, but for some reason the test kept failing.  I found the answer with this SO question.

In order to get the issue record to reflect the new value, I had to add reload after it.

it “should update status to in progress” do

  issue = FactoryGirl.create(:issue, status: “new”)

  Issue.method_to_update_status

  issue.reload.status.should eq “in progress”

end