Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Go
Code

Тестирование насыщенного данными кода с помощью Go, часть 3

by
Difficulty:IntermediateLength:MediumLanguages:
This post is part of a series called Testing Data-Intensive Code with Go.
Testing Data-Intensive Code With Go, Part 2
Testing Data-Intensive Code With Go, Part 4

Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)

Обзор

Это третья часть из пяти в серии руководств по тестированию насыщенного данными кода с помощью Go. Во второй части я рассмотрел тестирование на реальном слое данных в памяти на основе популярного SQLite. В этом руководстве я проведу тестирование на локальном сложном слое данных, который включает в себя реляционную БД и кэш Redis.

Тестирование на локальном уровне данных

Тестирование на уровне данных в памяти - это круто. Тесты молниеносны, и у вас есть полный контроль. Но иногда вам нужно быть ближе к фактической конфигурации вашего уровня производственных данных. Вот несколько возможных причин:

  • Вы используете конкретные детали своей реляционной БД, которые хотите протестировать.
  • Ваш слой данных состоит из нескольких взаимодействующих хранилищ данных.
  • Тестируемый код состоит из нескольких процессов, обращающихся к одному и тому же уровню данных.
  • Вы хотите подготовить или наблюдать ваши тестовые данные, используя стандартные инструменты.
  • Вы не хотите реализовывать выделенный слой данных в памяти, если ваш уровень данных постоянно меняется.
  • Вы просто хотите знать, что вы тестируете на своем реальном уровне данных.
  • Вам нужно протестировать с большим количеством данных, которые не помещаются в памяти.

Я уверен, что есть и другие причины, но вы можете понять, почему во многих случаях недостаточно использовать слой данных в памяти для тестирования.

Хорошо. Итак, мы хотим проверить фактический уровень данных. Но мы все еще хотим быть как можно более легкими и быстрыми. Это означает локальный уровень данных. Вот преимущества:

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

В этом уроке мы поднимем ставку. Мы реализуем (очень частично) гибридный уровень данных, который состоит из реляционной БД MariaDB и сервера Redis. Затем мы будем использовать Docker для поддержки локального уровня данных, который мы можем использовать в наших тестах.

Использование Docker для предотвращения головной боли при установке

Во-первых, вам нужен Докер. Проверьте документацию, если вы не знакомы с Docker. Следующим шагом будет получение образов для наших хранилищ данных: MariaDB и Redis. Не вдаваясь в подробности, MariaDB - это отличная реляционная БД, совместимая с MySQL, а Redis - отличное хранилище значений ключей в памяти (и многое другое).

Теперь, когда у нас установлен Docker и у нас есть образы для MariaDB и Redis, мы можем написать файл docker-compose.yml, который мы будем использовать для запуска наших хранилищ данных. Давайте назовем нашу БД "songify".

Вы можете запустить свои хранилища данных с помощью команды docker-compose up (аналогично vagrant up). Вывод должен выглядеть так:

На этом этапе у вас есть полноценный сервер MariaDB, прослушивающий порт 3306, и сервер Redis, прослушивающий порт 6379 (оба являются стандартными портами).

Гибридный уровень данных

Давайте воспользуемся преимуществами этих мощных хранилищ данных и обновим наш слой данных до гибридного слоя данных, который кэширует песни на пользователя в Redis. Когда вызывается GetSongsByUser(), слой данных сначала проверяет, есть ли в Redis песни для пользователя. Если это так, то просто вернем песни из Redis, но если этого не произойдет (потеря кэша), тогда он извлечет песни из MariaDB и заполнит кеш Redis, так что он уже будет готов к следующему вызову.

Вот определение структуры и конструктора. Структура сохраняет дескриптор БД, как и раньше, а также клиент Redis. Конструктор подключается как к реляционной БД, так и к Redis. Он создает схему и сбрасывает redis, только если соответствующие параметры имеют значение true, что необходимо только для тестирования. В производственной среде вы создаете схему один раз (игнорируя миграцию схемы).

Использование MariaDB

MariaDB и SQLite немного отличаются в том, что касается DDL. Различия небольшие, но важные. Go не имеет зрелого инструментария для работы с несколькими БД, как, например, фантастическая SQLAlchemy в Python, поэтому вам придется управлять им самостоятельно (нет, Gorm не в счет). Основными отличиями являются:

  • Драйвер SQL "github.com/go-sql-driver/mysql".
  • База данных не хранится в памяти, поэтому она каждый раз воссоздается (удаляется и создается).
  • Схема должна быть частью независимых операторов DDL вместо одной строки всех операторов.
  • Автоинкрементные первичные ключи отмечены как AUTO_INCREMENT.
  • VARCHAR вместо TEXT.

Вот код:

Использование Redis

Redis очень прост в использовании Go. Клиентская библиотека github.com/go-redis/redis очень интуитивно понятна и точно выполняет команды Redis. Например, чтобы проверить, существует ли ключ, вы просто используете метод Exits() клиента redis, который принимает один или несколько ключей и возвращает их количество.

В этом случае я проверяю только один ключ:

Тестирование доступа к нескольким хранилищам данных

Тесты на самом деле идентичны. Интерфейс не изменился, и поведение не изменилось. Единственное изменение заключается в том, что реализация теперь хранит кэш в Redis. Метод GetSongsByEmail() теперь просто вызывает refreshUser_Redis().

Метод refreshUser_Redis() возвращает пользовательские песни из Redis, если они существуют, и в противном случае извлекает их из MariaDB.

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

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

Заключение

В этом руководстве мы рассмотрели тестирование локального сложного слоя данных, состоящего из нескольких хранилищ данных (реляционная БД и кэш Redis). Мы также использовали Docker для простого развертывания нескольких хранилищ данных для тестирования.

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

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.