Моки по-прежнему могут быть полезны в случаях, когда требуется внешняя связь, например, со сторонними клиентами API, когда вы не отправляете реальные запросы к их серверам каждый раз при запуске тестов. Уровень базы данных также
Распространенной формой интеграционного тестирования является контекст веб-фреймворка. Вы делаете запрос к одной из ваших конечных точек и утверждаете, что получили ожидаемый ответ, либо проверяя тело ответа, либо просто утверждая, что вы получили ожидаемый код состояния. Давайте воспользуемся нашим блог-приложением из
Но прежде чем мы приступим к написанию наших интеграционных тестов, нам следует потратить некоторое время на изучение компонента 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 для получения дополнительной информации.
Возвращаясь к интеграционным тестам нашего блога, давайте начнем с тестирования контроллера статей, создав для их хранения новый файл:
require "../spec_helper"
struct ArticleControllerTest < ATH::Spec::APITestCase
end
Мы также можем удалить файл
APITestCase
предоставляет метод #request, который можно использовать для отправки запросов к нашему API, а также предоставляет вспомогательные методы для распространенных команд протокола передачи гипертекста (HTTP), таких как #get
и #post
. Он также реализован таким образом, что фактический тип HTTP::Server
не требуется. Это позволяет тестировать логику приложения быстрее и надежнее. Однако, как упоминалось в начале этой главы, тестирование E2E
также важно для проверки полного взаимодействия системы.
Начнем с тестирования конечной точки для получения конкретной статьи по идентификатору (ID), добавив следующий метод в ArticleControllerTest
:
def test_get_article : Nil
response = self.get "/article/10"