RSpect : need to be taken care of while writing UnitTesting

Ok let me show an example

let(:role) { create :role, name: 'parent' }
let(:user) { create(:user1, roles: [role]) }
let(:pact) { create :pact, parent_id:, renews_at: 1.hour.ago }

it 'should renew pact and also schedule the drug test whose renews_at date is today' do
  expect{execution}.to change{pact.pact_years.count}.by(1)
  expect(pact.renews_at).to eq(pact.renews_at + Pact::RenewalYear)
Failure/Error: expect(pact.renews_at).to eq(1.year.from_now)
 expected: 2017-02-28 09:20:41.204897017 +0000
 got: 2016-02-28 08:20:40.980794147 +0000

Did you notice what went wrong?. Well what I was doing wrong was, I was expecting the value of stale object to be updated by the execution.


it 'should renew pact and also schedule the drug test whose renews_at date is today' do
  expect{execution}.to change{pact.pact_years.count}.by(1)

  updated_pact = Pact.find(
  expect(updated_pact.renews_at).to eq(pact.renews_at + Pact::RenewalYear)
Failure/Error: expect(updated_pact.renews_at).to eq(pact.renews_at + Pact::RenewalYear)
 expected: 2017-02-28 08:27:50.125348477 +0000
 got: 2017-02-28 08:27:50.125348000 +0000

This time the issue was: I was comparing the DateTime object and for them to be equal, even the milli/micro seconds have to be equal.


updated_pact = Pact.find(
expect(updated_pact.renews_at.to_date).to eq(pact.renews_at.to_date + Pact::RenewalYear)
should renew pact and also schedule the drug test whose renews_at date is today
Finished in 5.76 seconds (files took 5.35 seconds to load)
4 examples, 0 failures, 2 pending


How to mock Stripe::Charge.retrieve using Stripe Mock gem

I created customer, made a subscription on the behalf of the customer. Along with that I generated invoices and expected in the RSpec example like


it 'should make sure reward amount in transaction history is equal \
    to amount added by the supporter.' do
  invoice = customer.invoices.first
  charge = Stripe::Charge.create(customer:, amount:, currency: 'usd').to_h
  charge[:id] = invoice.charge
  charge =
  allow(Stripe::Charge).to receive(:retrieve).and_return(charge) # A mock object would be more useful here.
  expect(TransactionHistory.first.added_rewards).to eq(

RSpec : Conditionals in before/after callbacks


When you add a conditions hash to before(:example) or before(:context), RSpec will only apply that hook to groups or examples that match the conditions. e.g.

RSpec.configure do |config|
  config.before(:example, :authorized => true) do

describe Something, :authorized => true do
  # The before hook will run in before each example in this group.

describe SomethingElse do
  it "does something", :authorized => true do
    # The before hook will run before this example.

  it "does something else" do
    # The hook will not run before this example.



config.before(:each) do |ex|
  if ex.metadata[:admin] == true
    Rails.application.load_seed # loading seeds

it "should auto fill the shipping date field to today's date", :admin => true  do
  expect(User.find_by_email('')).not_to eq(nil)


Rails : Capybara : When Checkboxes and Radio buttons are not found

There may come situation when you try to check(tick) the checkboxes via RSpec. using codes like



Problem was:

We have hidden the original checkbox and the fancy checkbox was being shown. Since the item was hidden Capybara was not able to find the element.


Instead of searching for hidden item, I triggered the click event on the Label for that Checkbox

within('.term-condition') do

Useful links

Rails : Capybara Webkit : Issue : Multiple JS events in single example

I recently moved from Selenium Web Driver to Thoughtbot’s Capybara Webkit as JS Driver for Capybara. The main reason is, webkit is super fast in running the test suite and its headless (no browser pops up ) .

Problem I faced

I was changing the option in select box and expecting the change in span’s content. Actually some sort of calculation should have been triggered. Webkit was not triggering the ‘change‘ event properly.

Continue reading

RSpec : Shared example group (it_behaves_like , include_examples , shared_examples )

You probably know how to use describe, context, it and specify to clearly communicate one aspect of your code. The nested context provides by it_behaves_like can be used to improve this communication with the reader.

I will base my example on the example given in the RSpec documentation for shared examples:

shared_examples "a collection" do
  context "initialized with 3 items" do
    it "says it has three items" do
      # ...

describe Array do
  it_behaves_like "a collection"
  include_examples "a collection"

If you run RSpec with --format documentation you get the following output:

  behaves like a collection
    initialized with 3 items
      says it has three items
  initialized with 3 items
    says it has three items

So the difference is how the spec is read eg in case of a failure.

Which style you prefer is a question of aesthetics of how you like your specs to read. Furthermore you would suggest to always use the same style if you work in a team to improve consistency.

Also, are it_should_behave_like and it_behaves_like just synonyms?

Almost, the context is named differently. it should behave like ... vs behaves like .... Again a question of aesthetics.