ROR : TDD / BDD with RSpec : Initial Setup ( Copied )

RSpec Setup in Rails 4

An up-to-date testing environment setup for Rails 4, including RSpec, Capybara, and FactoryGirl.

Gems

Gems gonna used are: Continue reading

Ruby : Rspec : Keep Specs Fresh With Anonymous Classes

Keep Specs Fresh With Anonymous Classes (Copied)

Sometimes it can be difficult to test a module since you don’t want to test it tied to a specific implementation. Let’s say we have a module that looks like this:

module MyModule
  def something?
    true 
  end
end

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
      # ...
    end
  end
end

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

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

Array
  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.

RSpec : Ruby On Rails : Different behavior of symbol/string in describe : TDD

Lets see the following example and understand how writing a ruby symbol instead a string make difference in describe block of RSpec.

RSpec.describe Applicant, type: :model do
  describe 'Validation' do
    it { is_expected.to validate_presence_of(:first_name) }
    it { is_expected.to validate_presence_of(:last_name) }
    it { is_expected.to validate_presence_of(:email) }
  end
end

Outputs
 should require first_name to be set
 should require last_name to be set
 should require email to be set

RSpec.describe Applicant, type: :model do
  describe :validation do
    it { is_expected.to validate_presence_of(:first_name) }
    it { is_expected.to validate_presence_of(:last_name) }
    it { is_expected.to validate_presence_of(:email) }
  end
end
Outputs:
 should require first_name to be set (FAILED - 1)
 should require last_name to be set (FAILED - 2)
 should require email to be set (FAILED - 3)

Conclusion: In the later example or code snippet, RSpec tried to find a class name :validation as subject. However, the the former example, ‘it’ block is expecting the class name in outer most describe block as subject.

Add Additional Library to Faker :: RSpec :: TDD

Suppose you are working on a project in which you want to test a Applicant Model. Applicant may have any value among options in a drop-down. If you want the spec should fill the education field with the data you wish, then you can modify the Faker module. To do so, the best way is the following

create a folder in spec/ directory
create a file called ‘anything_you_want.rb’

# inside the file 'anything_you_want.rb'
class Faker::Occupation
  def self.education
    list = ['High School', 'College', 'School']
    list.sample
  end
end

Un-comment the line from the file ‘rails_helper.rb’

Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }