Crystal Programming. Введение на основе проекта в создание эффективных, безопасных и читаемых веб-приложений и приложений CLI

      transformer = MockTransformer.new

      Processor.new(transformer).process "bar"

      transformer.transform_arg_value.should eq "bar"

    end

  end

end

Поскольку фиктивный преобразователь хранит значение, мы можем использовать его, чтобы гарантировать, что он был вызван с ожидаемым значением. Это позволит выявить случаи, когда он не вызывается или вызывается с неожиданным значением, что является ошибкой. Макетная реализация также не обязательно должна быть частной. Его можно было бы представить как часть самого проекта, чтобы конечный пользователь мог использовать его и в своих тестах.

Хуки

Основной принцип тестирования заключается в том, что каждый тестовый пример независим от других, например, не полагаясь на состояние предыдущего теста. Однако для нескольких тестов может потребоваться одно и то же состояние для проверки того, на чем они сосредоточены. Crystal предоставляет несколько методов как часть модуля Spec, которые можно использовать для определения обратных вызовов в определенных точках жизненного цикла теста.

Эти методы могут быть полезны для централизации настройки/удаления необходимого состояния для тестов. Например, предположим, что вы хотите убедиться, что глобальная переменная среды установлена перед запуском любого теста, и в нескольких тестовых случаях есть другая переменная, но нет других тестов. Для этого вы можете использовать методы .before_suite, #before_each и #after_each. Пример этого вы можете увидеть в следующем фрагменте кода:

require "spec"

Spec.before_suite do

  ENV["GLOBAL_VAR"] = "foo"

end

describe "My tests" do

  it "parentl" do

    puts "parent test 1: #{ENV["GLOBAL_VAR"]?}

      - #{ENV["SUB_VAR"]?}"

  end

describe "sub tests" do

  before_each do

    ENV["SUB_VAR"] = "bar"

  end

  after_each do

    ENV.delete "SUB_VAR"

  end

  it "child1" do

    puts "child test: #{ENV["GLOBAL_VAR"]?}

      - #{ENV["SUB_VAR"]?}"

  end

end

  it "parent2" do

    puts "parent test 2: #{ENV["GLOBAL_VAR"]?}

      - #{ENV["SUB_VAR"]?}"

  end

end

Этот пример делает именно то, что мы хотим. Метод .before_suite запускается один раз перед запуском любого теста, а методы #before_each и #after_each выполняются до/после каждого тестового примера в текущем контексте, например, определенного блока #describe. Запуск приведет к печати следующего:

parent test 1: foo -

child test: foo - bar

parent test 2: foo -

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

Другой тип перехвата — методы around_*. Вы можете думать о них как о комбинации методов «до» и «после», но позволяющей точно контролировать, когда и если выполняется тест или группа тестов. Например, мы могли бы упростить внутренний блок #describe из предыдущего примера, заменив хук «до/после» следующим:

around_each do |example|

  ENV["SUB_VAR"] = "bar"

  example.run

  ENV.delete "SUB_VAR"

end

В отличие от других блоков, этот метод возвращает тип Spec::Example, который предоставляет информацию о связанном тестовом примере, например его описание, теги и информацию о том, находится ли он в фокусе. Кроме того, в отличие от других блоков, тестовый пример необходимо выполнять вручную с помощью метода #run. Альтернативно, его можно вообще не выполнить, используя информацию из примера или другие внешние данные для определения этого.

Модульные тесты могут быть хорошим способом проверки конкретных частей приложения, но они не подходят для тестирования взаимодействия между этими частями. Для этого нам нужно будет начать использовать интеграционные/функциональные тесты.

Интеграционное тестирование

Общий процесс написания интеграционных тестов очень похож на модульное тестирование. Используются те же ожидания, может использоваться тот же синтаксис, а общие рекомендации/организационная структура также остаются прежними. Основное различие сводится к тому, что тестируется. Например, в предыдущем разделе мы создали макет, чтобы ограничить объем нашего теста. Однако в интеграционном тесте следует экономно использовать макеты, чтобы полностью протестировать реальную интеграцию ваших типов в приложении.