7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. Go

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

Scroll to top
Read Time: 7 mins
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
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
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.