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. Альтернативно, его можно вообще не выполнить, используя информацию из примера или другие внешние данные для определения этого.
Модульные тесты могут быть хорошим способом проверки конкретных частей приложения, но они не подходят для тестирования взаимодействия между этими частями. Для этого нам нужно будет начать использовать интеграционные/функциональные тесты.
Интеграционное тестирование
Общий процесс написания интеграционных тестов очень похож на модульное тестирование. Используются те же ожидания, может использоваться тот же синтаксис, а общие рекомендации/организационная структура также остаются прежними. Основное различие сводится к тому, что тестируется. Например, в предыдущем разделе мы создали макет, чтобы ограничить объем нашего теста. Однако в интеграционном тесте следует экономно использовать макеты, чтобы полностью протестировать реальную интеграцию ваших типов в приложении.
Моки по-прежнему могут быть полезны в случаях, когда требуется внешняя связь, например, со сторонними клиентами API, когда вы не отправляете реальные запросы к их серверам каждый раз при запуске тестов. Уровень базы данных также можно имитировать, но использование реальной тестовой базы данных может оказаться очень полезным, поскольку она является основной частью приложения.
Распространенной формой интеграционного тестирования является контекст веб-фреймворка. Вы делаете запрос к одной из ваших конечных точек и утверждаете, что получили ожидаемый ответ, либо проверяя тело ответа, либо просто утверждая, что вы получили ожидаемый код состояния. Давайте воспользуемся нашим блог-приложением из Главы 9 «Создание веб-приложения с помощью Athena» и напишем для него несколько интеграционных тестов.
Но прежде чем мы приступим к написанию наших интеграционных тестов, нам следует потратить некоторое время на изучение компонента Spec Athena, поскольку он будет использоваться для создания интеграционных тестов, но при желании его также можно использовать для модульного тестирования.
Компонент Athena Spec предоставляет часто полезные методы тестирования, а также альтернативный предметно-ориентированный язык (DSL) для написания тестов. В отличие от других сегментов тестирования, компонент Spec сводится к стандартным функциям модуля Spec, а не к переписыванию того, как пишутся и выполняются тесты.
Основная цель компонента Spec — обеспечить возможность повторного использования и расширения за счет использования более объектно-ориентированного подхода к программированию (ООП). Например, предположим, что у нас есть тип Calculator с методами #add и #subtract, которые выглядят следующим образом:
struct Calculator
def add(value1 : Number, value2 : Number) : Number
value1 + value2
end
def substract(value1 : Number, value2 : Number) : Number
value1 - value2
end
end
Пример тестового файла с использованием компонента Spec для нашего типа Calculator будет выглядеть следующим образом:
struct CalculatorSpec < ASPEC::TestCase
@target : Calculator
def initialize : Nil
@target = Calculator.new
end
def test_add
@target.add(1, 2).should eq 3
end
test "subtract" do
@target.subtract(10, 5).should eq 5
end
end
Каждый метод, начинающийся с test_, сводится к методу #it из модуля Spec. Макрос test также можно использовать для упрощения создания этих методов. Поскольку тесты определяются внутри структуры, вы можете использовать наследование и/или композицию, чтобы разрешить повторное использование логики для групп связанных тестов. Это также позволяет проектам предоставлять абстрактные типы, что упрощает создание тестов для определенных типов. Именно такой подход Athena Framework использовала в отношении своего типа ATH::Spec::APITestCase. См. https://athenaframework.org/Framework/Spec/APITestCase/ и https:// athenaframework.org/Spec/TestCase/#Athena::Spec::TestCase для получения дополнительной информации.
Возвращаясь к интеграционным тестам нашего блога, давайте начнем с тестирования контроллера статей, создав для их хранения новый файл: spec/controllers/article_controller_spec.cr. Затем добавьте в него следующий контент:
require "../spec_helper"
struct ArticleControllerTest < ATH::Spec::APITestCase
end
Мы также можем удалить файл spec/blog_spec.cr по умолчанию.
APITestCase предоставляет метод #request, который можно использовать для отправки запросов к нашему API, а также предоставляет вспомогательные методы для распространенных команд протокола передачи гипертекста (HTTP), таких как #get и #post. Он также реализован таким образом, что фактический тип HTTP::Server не требуется. Это позволяет тестировать логику приложения быстрее и надежнее. Однако, как упоминалось в начале этой главы, тестирование E2E также важно для проверки полного взаимодействия системы.
Начнем с тестирования конечной точки для получения конкретной статьи по идентификатору (ID), добавив следующий метод в ArticleControllerTest:
def test_get_article : Nil
response = self.get "/article/10"
pp response.status, response.body
end
Прежде чем мы сможем опробовать этот тестовый пример, нам сначала нужно сообщить spec/spec_helper.cr об абстрактном типе тестового примера, а также настроить его для запуска наших тестов на основе
