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

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

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 3
Testing Data-Intensive Code With Go, Part 5

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

Обзор

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

В этом руководстве я расскажу о тестировании с удаленными хранилищами данных с использованием общих тестовых баз данных, с использованием моментальных снимков производственных данных и создания собственных тестовых данных.

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

До сих пор все наши тесты проводились локально. Иногда этого недостаточно. Возможно, вам придется проверить данные, которые сложно сгенерировать или получить локально. Тестовые данные могут быть очень большими или часто изменяться (например, снимок производственных данных).

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

Здесь есть несколько вариантов для рассмотрения. Вы можете использовать один или несколько из этих вариантов в разных ситуациях.

Общая тестовая база данных

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

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

Удаленный запуск тестов

Так работают конвейеры CI / CD или даже просто автоматизированные системы сборки. Разработчик фиксирует изменение и запускает автоматическую сборку и тестирование. Но вы также можете просто подключиться к удаленной машине с вашим кодом и запустить там свои тесты.

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

Ad-Hoc удаленный тестовый экземпляр

Запуск удаленного специального тестового экземпляра гарантирует, что вы по-прежнему изолированы от других разработчиков. Концептуально это очень похоже на запуск локального экземпляра. Вам все еще нужно запустить свое хранилище данных (или хранилища). Вам все еще нужно заполнить их (удаленно). Тем не менее, ваш тестовый код выполняется локально, и вы можете отлаживать и устранять неполадки, используя вашу любимую среду IDE (в моем случае Gogland). Оперативно управлять может быть, если разработчики продолжают запускать тестовые экземпляры после завершения тестов.

Использование снимков производственных данных

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

Плюсы и минусы использования производственных данных для тестирования

Плюсы:

  • Вы проверяете на реальных данных. Если это работает, всё в порядке.
  • Вы можете загрузить и данные теста производительности, которые представляют фактическую нагрузку.
  • Вам не нужно писать генераторы данных, которые пытаются симулировать реальные производственные данные.

Минусы:

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

Анонимизация производственных данных

Хорошо. Вы сделали скачок и решили использовать снимок производственных данных. Если ваши данные касаются людей в любой форме, вам, возможно, придется анонимизировать данные. Это на удивление сложно.

Вы не можете просто заменить все имена и покончить с этим. Есть много способов восстановить PII (личную информацию) и PHI (защищенную медицинскую информацию) из плохо анонимизированных снимков данных. Проверьте Википедию, если вам интересно.

Я работаю в Helix, где мы разрабатываем личную платформу геномики, которая работает с самыми частными данными - последовательной ДНК людей. У нас есть несколько серьезных мер защиты от случайных (и злонамеренных) нарушений данных.

Обновление тестов и моментальных снимков данных

При использовании снимков производственных данных вам придется периодически обновлять снимки и, соответственно, тесты. Время зависит от вас, но определенно делайте это всякий раз, когда происходит изменение схемы или формата.

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

Генерация тестовых данных

Другой подход заключается в создании собственных тестовых данных. Плюсы и минусы являются точными противоположностями использования моментальных снимков производственных данных. Обратите внимание, что вы также можете объединить два подхода и запустить некоторые тесты для моментальных снимков производственных данных и другие тесты, используя сгенерированные данные.

Генерация случайных данных

Что вы думаете о создании ваших тестовых данных? Можно пойти другим способом и использовать совершенно случайные данные. Например, для Songify мы можем просто генерировать совершенно случайные строки для электронной почты пользователя, URL, описания и меток. Результат будет хаотичным, но действительными данными, поскольку Songify не выполняет никакой проверки данных.

Вот простая функция для генерации случайных строк:

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

Теперь мы можем написать несколько тестов, которые оперируют большим количеством данных. Например, вот тест, который проверяет, что мы можем получить все 100 песен за один звонок. Обратите внимание, что тест вызывает PopulateWithRandomData() перед выполнением вызова.

Генерация тестовых данных на основе правил

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

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

Например, допустим, мы хотим применить правило, согласно которому пользователь может иметь не более 30 песен. Вместо случайного создания 100 песен и назначения их пользователям, мы можем решить, что у каждого пользователя будет ровно 20 песен, или, возможно, создать одного пользователя без песен и четырех других пользователей по 25 песен в каждой.

Генерация тестовых данных на основе повествования

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

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

Заключение

В этом руководстве мы рассмотрели тестирование с использованием удаленных хранилищ данных, использование общих тестовых баз данных, использование моментальных снимков производственных данных и создание собственных тестовых данных.

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

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.