Terraform: инфраструктура на уровне кода

Концепция автоматического тестирования состоит в том, что для проверки поведения настоящего кода пишутся тесты. В главе 8 вы узнаете, что с помощью CI-сервера эти тесты можно запускать после каждой отдельной фиксации. Если они не будут пройдены, фиксацию сразу же можно отменить или исправить. Таким образом, ваш код всегда будет в рабочем состоянии.

Существует три типа автоматических тестов.

• Модульные тесты. Проверяют функциональность одного небольшого фрагмента кода — модуля. Его определение может варьироваться, но в языках программирования общего назначения под ним понимают отдельную функцию или класс. Внешние зависимости (например, базы данных, веб-сервисы и даже файловая система) заменяются тестовыми mock-объектами. Это позволяет полностью контролировать их поведение (например, mock-объект базы данных может возвращать ответ, прописанный вручную) и убедиться в том, что ваш код справляется с множеством разных сценариев.

•Интеграционные тесты. Проверяют корректность совместной работы нескольких модулей. В языках программирования общего назначения интеграционный тест состоит из кода, который позволяет убедиться в корректном взаимодействии нескольких функций или классов. Реальные зависимости используются вперемешку с mock-объектами: например, если вы тестируете участок приложения, который обращается к базе данных, стоит тестировать его с настоящей БД, а другие зависимости, скажем, систему аутентификации, заменить mock-объектами.

•Сквозные тесты. Подразумевают запуск всей вашей архитектуры (например, приложений, хранилищ данных, балансировщиков нагрузки) и проверку работы системы как единого целого. Обычно эти тесты выполняются как бы от имени конечного пользователя: допустим, Selenium может автоматизировать взаимодействие с вашим продуктом через браузер. В сквозном тестировании везде используются реальные компоненты без каких-либо mock-объектов, а архитектура при этом является отражением настоящей промышленной системы (но с меньшим количеством или с менее дорогими серверами, чтобы сэкономить).

У каждого типа тестов свое назначение, и с их помощью можно выявить разного рода ошибки, поэтому их стоит применять совместно. Модульные тесты выполняются быстро и позволяют сразу получить представление о внесенных изменениях и проверить разнообразные комбинации. Это дает уверенность в том, что элементарные компоненты вашего кода (отдельные модули) ведут себя так, как вы ожидали. Однако тот факт, что модули работают корректно по отдельности, вовсе не означает, что они смогут работать совместно, поэтому, чтобы убедиться в совместимости ваших элементарных компонентов, нужны интеграционные тесты. С другой стороны, корректное поведение разных частей системы не гарантирует, что эта система будет работать как следует после развертывания в промышленной среде, поэтому, чтобы проверить ваш код в условиях, приближенных к реальным, необходимы сквозные тесты.

Теперь посмотрим, как писать тесты каждого из этих типов для кода Terraform.

Модульные тесты

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

class WebServer < WEBrick::HTTPServlet::AbstractServlet

  def do_GET(request, response)

    case request.path

    when "/"

      response.status = 200

      response['Content-Type'] = 'text/plain'

      response.body = 'Hello, World'

    when "/api"

      response.status = 201

      response['Content-Type'] = 'application/json'

      response.body = '{"foo":"bar"}'

    else

      response.status = 404

      response['Content-Type'] = 'text/plain'

      response.body = 'Not Found'

    end

  end

end

Создание модульного теста для этого кода усложняется тем, что вам нужно выполнить несколько действий.

1. Создать экземпляр класса WebServer. Это сложнее, чем кажется, так как конструктору WebServer, который наследует AbstractServlet, необходимо передать целый класс HTTPServer из WEBrick. Вы могли бы создать его mock-объект, но это потребовало бы много усилий.

2. Создать объект request типа HTTPRequest. Получение экземпляра этого класса, равно как и создание его mock-объекта, требует довольно большого объема работы.

3. Создать объект response типа HTTPResponse. Опять же экземпляр этого класса нельзя получить легким путем, а для создания его mock-объекта нужно много усилий.

Если вам сложно писать модульные тесты, это часто говорит о плохом качестве кода и является поводом для рефакторинга. Чтобы облегчить модульное тестирование, обработчики (то есть код, который обрабатывает пути /, /api и «Страница не найдена») можно вынести в отдельный класс Handlers:

class Handlers

  def handle(path)

    case path

    when "/"

      [200, 'text/plain', 'Hello, World']

    when "/api"

      [201, 'application/json', '{"foo":"bar"}']

    else

      [404, 'text/plain', 'Not Found']

    end

  end

end

У этого нового класса есть два ключевых свойства.