Writing a test for a case statement in Ruby

Question

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

Yes, to test every path through this code, you will need to write a test for each `when`. — slim, Dec 20 '16 at 16:37
This is a really contrived example. Most of the time you'll need to make a number of exercise cases where a series of events are performed. Sometimes these get so complicated that you'll want to specify the input and expected output in a series of case files stored as JSON or YAML for simplicity. Make sure you not only execute all possible paths, but a representative sample of invalid paths as well, like empty strings, `nil` values, or invalid input like `$`. — tadman, Dec 20 '16 at 19:10

score 4 · Accepted Answer · edited May 23 '17 at 12:02

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

`assert_output` is the most functional way to test this concept since we cannot rely on the the return value (which will always be nil) — engineersmnky, Dec 20 '16 at 21:27

phortx · Answer 2 · 2016-12-21T07:27:30.853

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

`user_answer` refers to the method created by `attr_reader :user_answer`. It returns `@user_answer`. — Sagar Pandya, Dec 20 '16 at 16:55
Although you're on the right track here none of this will work because `puts` returns `nil`. The original code is not easily tested, but could be adapted to be more friendly. — tadman, Dec 20 '16 at 19:09
This is super useful!! Although the first method didn't work, the second way did after the refactor you commended! — Quintessa Anderson, Jul 15 '19 at 23:38

Writing a test for a case statement in Ruby

2 Answers2