Методы и рекомендации по тестированию персистентности сущностей

Question

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

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

Answer 1

Последние шесть лет или около того я в основном использовал NHibernate для персистентности.

На уровне модульных тестов я использую SQLite в памяти для тестирования сопоставлений персистентности / сущностей и интеграцииУровень тестирования Я использовал реальный сервер базы данных (локально и на сервере сборки).

В обоих случаях я настраивал базу данных с помощью сценариев, которые NHibernate / Fluent NHibernate может создать для вас каждый тест (и последующее уничтожение БД в случае интеграции).Это занимает больше времени для запуска, но ИМХО риск того, что код очистки испортится, еще хуже (кстати, об этом есть обсуждение в книге xUnit Test Patterns).

Answer 2

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

Что касается базы данных, в моем текущем проекте костюм интеграционного теста действительно отбрасывает всю схему и воссоздает все с нуля (это используется, когда тесты запускаются с сервера сборки). Тем не менее, вы также можете запускать тесты для уже созданной базы данных - это имеет смысл, если вы тестируете / отлаживаете со своей машины и не хотите тратить время или терять тестовые данные. Вы ДОЛЖНЫ поддерживать свои скрипты базы данных (они должны быть такими же, как и для производственных) - таким образом вы тестируете свои скрипты, а также ваш .Net код. В общем случае сценарии не создают никаких данных (возможно, кроме статических данных) - они должны быть частью тестов для создания тестовых данных, выполнения некоторых операций над ними и проверки ожиданий - чтобы вы могли выполнять свои тесты для каждой базы данных с правильная схема. При создании тестовых данных мы обычно берем случайные идентификаторы и уникальные поля и жестко кодируем все остальное.

Что касается управления средой, у вас уже должен быть какой-то механизм для настройки соединения с базой данных (чтобы вы могли иметь тестовую и производственную среды) - есть много способов сделать это, включая продукты Microsoft и собственные решения - так вы должны использовать тот же способ для настройки вашей машины сборки.

Answer 3

Мой подход заключается в создании набора интеграционных тестов, которые используются для тестирования уровня доступа к данным (репозитории и отображение). Я думаю, что это очень важно, если вы используете инструмент ORM, который использует подход «соглашение поверх конфигурации», например, отображение POCO в EF. У меня есть скрипт инициализации БД, который создает новую базу данных (такую ​​же, как текущая БД разработки) и создает начальный набор тестовых данных. Этот скрипт запускается только один раз в начале теста. База данных удаляется в конце выполнения тестов. Каждый интеграционный тест использует транзакцию, которая откатывается в конце теста, поэтому данные теста одинаковы для всех тестов. Для проверки данных в БД я использую вспомогательные классы со стандартным подходом SqlCommand. Чтобы использовать SqlCommand, вы должны использовать уровень изоляции транзакции ReadUncommited для своих тестов, потому что вы обычно не разделяете соединение между SqlCommand и EF-контекстом.