RSpec: How do I refactor a group of tests that are repeated and the only thing that changes is the subject and expectations - refactoring

I have a test suite that resembles the situation I describe with the following code. There are two contexts that define the subject. The subject is similar, the same kind of object, but with different values.
Over that subject I run two tests. One test is exactly the same for both and the other is different.
Suggest a refactor that would eliminate duplication, besides the obvious 'move the code to a method', which I don't like because it looses clarity.
require 'rspec'
describe "tests over numbers" do
context 'big numbers' do
subject { 5000 }
describe "#to_string" do
its(:to_s) {should be_a(String)}
end
describe "#+1" do
it "+1" do
sum = subject+1
sum.should == 5001
end
end
end
context 'small numbers' do
subject { 100 }
describe "#to_string" do
its(:to_s) {should be_a(String)}
end
describe "#+1" do
it "+1" do
sum = subject+1
sum.should == 101
end
end
end
end

Maybe shared examples is the way to go?
shared_example "numbers" do
describe "#to_string" do
it "should convert to a string" do
example.to_s.should be_a(String)
end
end
describe "#+1" do
it "should increment" do
sum = example+1
sum.should == example.next
end
end
end
describe "big_numbers" do
it_behaves_like "numbers" do
let(:example) { 5000 }
end
end
describe "small_numbers" do
it_behaves_like "numbers" do
let(:example) { 100 }
end
end

[5000, 100].each do |my_test|
subject { my_test }
describe "#to_string" do
its(:to_s) {should be_a(String)}
end
describe "#+1" do
it "+1" do
sum = subject+1
sum.should == my_test + 1
end
end
end

Related

How to write rspec for logic and write mock STDIN

I am a very new coder and trying to write rspec for a class that test the conditional statement/logic. I started sudo coding for it but I was told to make mock STDIN which I don't know how to. Can someone please write the rspec for the class or give me a few idea how to create a mock STDIN. I need help writing rspec for the conditional statement/logic, if some can please just write the test for one of the context then I can do rest based on that.
require 'rails_helper'
module BAB::ACA
RSpec.describe partfinder do
describe '#find_part_id' do
let(:face) { create(:face) }
subject { described_class.find_part_id(face) }
context 'When bab con already exists' do
context 'when there are more than one part ids' do
#create part ids
context 'when user input matches an existing id' do
#mock STDIN that matches an existing, subject should equal that id
end
context 'when user input does not match an existing id' do
# mock STDIN that does match existing id, should return failure message
end
end
context 'when there is only one bab part id' do
# subject should equal the one that already exists
end
end
context 'when av con does not yet exist' do
# mock STDIN and make sure subject equals what you mocked
end
end
end
module BAB::ACA
class partfinder
def self.find_part_id(face)
av_con = BAB::Child:Fail.find_by(
face: face
reg: BAB:Child.find_reg
)
if av_con
look_id(face, av_con)
end
else
puts "What is #{face.name} BAB part id? must be 6"
STDIN.gets.chomp
end
end
def self.look_id(face, av_con)
if av_con.part_ids.length > 1
ask_for_id(face, av_con)
else
av.con.part_ids.first
end
end
def self.ask_for_id(face, av_con)
puts "What is #{face.name} BAB part id? "
bab_part_id = STDIN.gets.chomp
unless av.con.part_ids.include?(bab_part_id)
fail 'Entered id doesn't match'
end
bab_part_id
end
end
end
You can use method stubs.
In this case you want to stub STDIN.gets.chomp, so you'd do something like this:
describe '#find_part_id' do
before do
allow(STDIN.gets).to receive(:chomp).and_return(stdin_input)
end
let(:stdin_input) { 'user input from stdin' }
let(:face) { create(:face) }
subject { described_class.find_part_id(face) }
context 'When bab con already exists' do
context 'when there are more than one part ids' do
it 'some test' do
# your test here
end
end
# more contexts...
context 'a context that needs a different stdin_input' do
let(:stdin_input) { 'some different user input from stdin' }
it 'another test' do
# your test here
end
end
end
end
Where stdin_input is the string you want the user to enter for your tests.

Writing a test for a case statement in Ruby

I'm trying to write a test for a case statement using minitest. Would I need to write separate tests for each "when"? I included my code below. Right now it just puts statements, but eventually it's going to redirect users to different methods. Thanks!
require 'pry'
require_relative 'messages'
class Game
attr_reader :user_answer
def initialize(user_answer = gets.chomp.downcase)
#user_answer = user_answer
end
def input
case user_answer
when "i"
puts "information"
when "q"
puts "quitter"
when "p"
puts "player play"
end
end
end
This answer will help you. Nonetheless I'll post one way of applying it to your situation. As suggested by #phortx when initializing a game, override the default user-input with the relevant string. Then by using assert_output we can do something like:
#test_game.rb
require './game.rb' #name and path of your game script
require 'minitest/autorun' #needed to run tests
class GameTest < MiniTest::Test
def setup
#game_i = Game.new("i") #overrides default user-input
#game_q = Game.new("q")
#game_p = Game.new("p")
end
def test_case_i
assert_output(/information\n/) {#game_i.input}
end
def test_case_q
assert_output(/quitter\n/) {#game_q.input}
end
def test_case_p
assert_output(/player play\n/) {#game_p.input}
end
end
Running the tests...
$ ruby test_game.rb
#Run options: --seed 55321
## Running:
#...
#Finished in 0.002367s, 1267.6099 runs/s, 2535.2197 assertions/s.
#3 runs, 6 assertions, 0 failures, 0 errors, 0 skips
You have to test each case branch. Via RSpec it would work that way:
describe Game do
subject { Game }
describe '#input' do
expect_any_instance_of(Game).to receive(:puts).with('information')
Game.new('i').input
expect_any_instance_of(Game).to receive(:puts).with('quitter')
Game.new('q').input
expect_any_instance_of(Game).to receive(:puts).with('player play')
Game.new('p').input
end
end
However due the fact that puts is ugly to test, you should refactor your code to something like that:
require 'pry'
require_relative 'messages'
class Game
attr_reader :user_answer
def initialize(user_answer = gets.chomp.downcase)
#user_answer = user_answer
end
def input
case user_answer
when "i"
"information"
when "q"
"quitter"
when "p"
"player play"
end
end
def print_input
puts input
end
end
Then you can test with RSpec via:
describe Game do
subject { Game }
describe '#print_input' do
expect_any_instance_of(Game).to receive(:puts).with('quitter')
Game.new('q').print_input
end
describe '#input' do
expect(Game.new('i').input).to eq('information')
expect(Game.new('q').input).to eq('quitter')
expect(Game.new('i').input).to eq('player play')
expect(Game.new('x').input).to eq(nil)
end
end

rspec vote validations error: must pass hash as an argument

I am trying to write a spec code for a vote_spec model. Not sure what exactly it is I'm doing wrong. I think it may be in the first #vote attribute in the before block.
This is how the validations should work:
Console
v = Vote.new(value: 1)
v.valid? #=> true
v2 = Vote.new(value: -1)
v2.valid? #=> true
v3 = Vote.new(value: 2)
v3.valid? #=> false
This is the error:
Failure/Error: #vote = Vote.create(:post_id)
ArgumentError:
When assigning attributes, you must pass a hash as an argument.
This is my vote_spec.rb
require 'rails_helper'
describe Vote do
describe "validations" do
before do
#vote = Vote.create(:post_id)
#vote.create(value: 1)
#vote.create(value: -1)
end
describe "first_validation" do
it "only allows -1 as a value" do
expect(#vote.first_validation).to eq(-1)
end
end
describe "second_validation" do
it "only allows 1 as a value" do
expect(#vote.second_validation).to eq(1)
end
end
end
end
If you want to test validation, maybe you could do something like this:
describe "validations" do
it 'is valid if the value is 1' do
expect(Vote.new(value: 1)).to be_valid
end
it 'is valid if the value is -1' do
expect(Vote.new(value: -1)).to be_valid
end
[-3, 0, 4].each do |invalid_value|
it "is not valid if the value is #{invalid_value}" do
expect(Vote.new(value: invalid_value)).not_to be_valid
end
end
end
Amanjot,
Also as Sasha mentioned in the comments. You can just continue with this below code I think
require 'rails_helper'
describe Vote do
describe "validations" do
before do
#first_vote = Vote.create(value: -1) # Vote.new(value: -1) - should try this too
#second_vote= Vote.create(value: 1) # Vote.new(value: 1) - should try this too
end
describe "first_validation" do
it "only allows -1 as a value" do
expect(#first_vote.value).to eq(-1)
end
end
describe "second_validation" do
it "only allows 1 as a value" do
expect(#second_vote.value).to eq(1)
end
end
end
Try out something like this. You would need to use the create action on the Vote model.

Testing with Rspec - The correct way

My weakest point when it comes to coding, is using TDD & BDD methods - I tend to just write code.. but it is something that I am trying to work on.
Could anyone point out the best way to go about the following problem:
Class1:
module TempMod
class MyClass
def initalize(config)
#config = config
end
def process(xml)
if react_upon? xml.something
puts 'yeah'
else
puts 'nah'
end
end
def react_upon?(xml_code)
#code here
end
end
end
So lets say I wanted to test this class, or build it from a TDD point of view so I write my tests:
describe TempMod::MyClass do
let(:config) {double}
let(:myclass) {TempMod::MyClass.new config}
context 'Given that the xml is something we react upon' do
it 'should check that it is valid' do
myclass.process '<some><xml>here</xml></some>'
end
it 'should output yea'
end
end
How do I test that it is calling the react_upon? method. Do I even want to see it is calling it?
Is the proper way to test it, to test all the functions like the react_upon? itself independently of the other functions?
This is properly the main thing that is most confusing me with this sort of testing. Am I testing the whole class, or just individually testing the functions, and not their interactions with the other functions in that class?
Also I realize the the react_upon? might not adhere to the Single responsibility principle and I would probably move that out to its own module/class which I could test using a stub.
If anyone can shed some light on this for me that would be awesome.
edit:
describe TempMod::MyClass do
let (:valid_planning_status_xml) {
'<StatusUpdate> <TitleId>2329</TitleId> <FromStatus>Proposed</FromStatus> <ToStatus>Confirmed</ToStatus> </StatusUpdate>'
}
let(:config) { double }
let(:status_resolver) { double }
subject(:message_processor) { TempMod::MyClass.new config, status_resolver }
context 'Given that the message XML is valid' do
it 'should check the context of the message' do
expect(message_processor.process valid_planning_status_xml).to call :check_me
end
context 'Given that the message is for a planning event update' do
it 'should call something' do
pending
end
end
context 'Given that the message is for a recording job update' do
end
context 'Given that the message is for a video title update' do
end
end
end
Your question confused me a bit is this what you are asking
module TempMod
class MyClass
def initalize(config)
#config = config
end
def process(xml)
react_upon?(xml.something) ? 'yeah' : 'nah'
end
def react_upon?(xml_code)
#code here
end
end
end
Then test like
describe TempMod::MyClass do
let(:config) {double}
let(:myclass) {TempMod::MyClass.new config}
context 'Given that the xml is something we react upon' do
it "should respond to react_upon?" do
expect(myclass).to respond_to(:react_upon?)
end
it "should react_upon? valid xml" do
expect(myclass.react_upon?(YOUR VALID REACTION GOES HERE)).to be_true
end
it "should not react_upon? invalid xml" do
expect(myclass.react_upon?(YOUR INVALID REACTION GOES HERE)).to be_false
end
it "should say 'yeah' if it is valid" do
expect(myclass.process('<some><xml>here</xml></some>')).to eq('yeah')
end
it "should say 'nah' if it is invalid" do
expect(myclass.process('<some><xml>here</some>')).to eq('nah')
end
it 'should check the context of the message' do
expect(myclass).to receive(:react_upon?).with('<some><xml>here</xml></some>')
myclass.process('<some><xml>here</xml></some>')
end
end
end
Right now your tests have no expectations so I added one that expects myclass to respiond_to the react_upon? method and another that expects myclass.process(xml) to respond with a String that equals yeah.

Rspec to have(n).items undefined method

I'm trying to follow a guide on code.tuts and I keep getting an error.
Here is my Library spec:
require 'spec_helper'
describe Library do
before :all do
lib_arr = [
Book.new("JavaScript: The Good Parts", "Douglas Crockford", :development),
Book.new("Dont Make me Think", "Steve Krug", :usability),
]
File.open "books.yml", "w" do |f|
f.write YAML::dump lib_arr
end
end
before :each do
#lib = Library.new "books.yml"
end
describe "#new" do
context "with no parameters" do
it "has no book" do
lib = Library.new
expect(lib).to have(0).books
end
end
context "with a yaml file name parameters" do
it "has two books" do
expect(#lib).to_have(0).books
end
end
end
it "returns all the books in a given category" do
expect(#lib.get_books_in_category(:development).length).to eql 1
end
it "accepts new books" do
#lib.add_book(Book.new("Designing for the Web", "Mark Boulton", :design))
expect(#lib.get_book("Designing for the Web")).to be_an_instance_of Book
end
it "saves the library" do
books = #lib.books.map { |book| book.title}
#lib.save
lib2 = Library.new 'books.yml'
books2 = lib2.books.map { |book| book.title }
expect(books).to eql books2
end
end
I'm getting that have is undefined. I've figured out it's my lines
expect(#lib).to have(0).books
expect(lib).to have(0).books
Is my syntax out of date? I've googled and I can't find it.
The have/have_exactly, have_at_least and have_at_most matchers were removed from RSpec 3. They're now in the separate rspec-collection_matchers gem.
Or, as zishe says, instead of installing the gem, you can just use eq instead of have/have_exactly, and be >= instead of have_at_least and be <= instead of have_at_most.
Source: http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3

Resources