В этом посте мы продолжим разбирать RSpec и поговорим о matchers.

“Matchers” не переводится с английского, но слово match в этом контексте означает “совпадать, равняться”.

Итак.

RSpec “вешает” методы to и not_to на все результаты ожиданий.

Эти два метода принимают один параметр — matcher.

Примеры matcher’ов:

• be_true / be_false
• eq 3
• raise_error(SomeError)

Be_predicate — логическое значение

Если объект, на котором проводится тест, имеет утвердительный (логический) метод, вы автоматически получите матчер be_predicate.

Так что, к примеру, be_nil является валидным матчером, так как каждый объект в Ruby имеет метод :nil?.

В нашем примере с калькулятором мы можем иметь такой тест:

it "should sum two odd numbers and become even" do
 expect(@calculator.add(3, 3)).to be_even
 expect(@calculator.add(3, 3)).not_to be_odd
end

Это полностью валидно и выглядит почти как естественный английский.

Так как мы исправили ошибки в калькуляторе, все тесты работают.

Но если вы хотите узнать подробнее, что работает, а что нет, введите rspec --format documentation или rspec -f d:

Больше матчеров

Полный список матчеров можно найти в документации RSpec.

https://relishapp.com/rspec/rspec-expectations/v/3-6/docs/built-in-matchers

В итоге

RSpec имеет множество встроенных матчеров, которые доступны для упрощения написания тестов, я думаю это отличный фреймворк для тестирования приложений.

Хотя если вы предпочитаете MiniTest, используйте его.

В этом посте мы продолжим говорить о юнит-тестировании в Ruby и рассмотрим RSpec.

Тестирование с помощью RSpec

Test::Unit делает свою работу, но было бы неплохо, если бы тесты были более описательными, более похожими на естественный английский.

RSpec позволяет это.

Так что, здесь написание тестов более интуитивно, как и вывод после выполнения тестов.

Установка RSpec

Устанавливаем RSpec командой gem install rspec.

describe()

Метод describe() это набор связанных тестов.

Он принимает строку либо класс в качестве аргумента.

Все тесты должны быть внутри этого блока.

Здесь нет подкласса для класcа (в отличие от Test::Unit), всё происходит внутри метода describe().

Методы before() и after()

Методы before() и after() похожи на setup() и teardown() в MiniTest.

Они принимают значения :each или :all, чтобы указать будет блок выполняться перед/после каждого теста или один раз перед/после всех тестов.

К примеру, before :all был бы полезен, если вы хотите подключиться к базе данных лишь единожды.

Метод it()

Используется для определения фактических спецификаций/примеров RSpec.

Принимает опциональную строку, описывающую тестируемое поведение.

Пример

Давайте возьмем для примера тот же код калькулятора, который был в предыдущей статье, но в этот раз протестируем его с помощью RSpec.

class Calculator

  attr_reader :name

  def initialize(name)
  	@name = name
  end

  def add(one, two)
  	one - two # скажем, вы допустили ошибку здесь (- вместо +)
  end

  def subtract(one, two)
  	one + two # и в этом методе
  end

  def divide(one, two)
  	one / two
  end
end

Выполним в терминале команду rspec --init в нужной папке, чтобы всё было подготовлено.

spec/calculator_spec.rb:

require 'rspec'
require_relative '../calculator' # или calculator.rb, без разницы

describe Calculator do # здесь вместо класса Calculator можно быть бы написать строку, но здесь это не имеет смысла
  before { @calculator = Calculator.new('RSpec calculator')}

# Фактические спецификации:

  it "should add 2 numbers correctly" do
  	expect(@calculator.add(2, 2)).to eq 4 
  end
  	
  it "should subtract 2 numbers correctly" do
   expect(@calculator.subtract(4, 2)).to eq 2 
  end  

  it "should sum two odd numbers and become even" do
   expect(@calculator.add(3, 3)).to be_even 
   expect(@calculator.add(3, 3)).not_to be_odd 
  end

end

Как мы видим, RSpec более интуитивный и больше похож на естественный английский.

Выполняем команду rspec.

После устранения ошибок результат выполнения теста будет выглядеть так:

В итоге, если вам нравится MiniTest, можете использовать его. Если вам нравится выразительность RSpec, попробуйте это.

Много раз вам придется писать тесты. Некоторые делают это после написания основного кода, некоторые после. Но в целом это довольно важная часть.