Шаблоны для загрузки данных по умолчанию при модульном тестировании

Question

Ищите несколько стратегий загрузки данных по умолчанию при выполнении юнит-тестов.

Answer 1

Я использую конструктор, который содержит значения по умолчанию, вот так: http://elegantcode.com/2008/04/26/test-data-builders-refined/. Тогда в тесте указывается только значение, которое ему нужно:

Customer customer = new CustomerBuilder()
   .WithFirstName("this test only cares about a special ' ... first name value");

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

Это вопрос удобства / упрощения тестов, много раз вы тестируете очень специфическое поведение, которое зависит от 1-3 полей, и вас не волнуют остальные поля.

Answer 2

TDD - это тестирование кода в изоляции .Создайте экземпляр класса с его зависимостями (или имитирует их), вызовите тестируемый метод и подтвердите, чтобы проверить результат теста.

Обычно с TDD начинается с простого теста без данных.Когда данные необходимы, они создаются в тестовом приспособлении (изолированной среде, в которой выполняется тест) методом теста setUp() и затем уничтожаются методом tearDown() после запуска теста.Данные не загружаются из базы данных.

Answer 3

Предпочтительной стратегией являются данные транзакций. Spring предлагает расширенную поддержку (как для JUnit 3, так и для 4). С помощью этой стратегии ваш тест начинает новую транзакцию каждый раз, а ваши данные откатываются в конце теста.

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

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

Answer 4

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

При выборе значений для отправки в базу данных я использую GUID (или другие случайные значения), когда это возможно, поскольку это гарантирует, что значения в базе данных являются уникальными (например, если вы создаете кого-то с именем «Mr XY», онполезно знать , что поиск "X" должен возвращать только 1 результат, и что нет никаких шансов, что вы случайно натолкнулись на кого-то еще в базе данных, чья фамилия случается , чтобы быть Y)

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

Если тестируемый API не имеет методов для записи в базу данных, янаписать свой собственный набор вспомогательных функций - точная структура будет зависеть от источника данных, но в качестве примера я часто использую LINQ to SQL.

Answer 5

У меня обычно есть методы, такие как GetCustomer (), которые возвращают общего клиента. Если мне нужно настроить возвращаемый клиентский набор на мои потребности для определенного теста, я просто изменю свойство после его возвращения.

В других случаях я могу передать некоторую информацию о конфигурации в мой метод GetCustomer (). Например, GetCustomer (строка customerType).

Я прочитал мнения экспертов, согласно которым каждый тест должен содержать свои собственные уникальные данные для работы, а не пытаться сделать данные общими. Несмотря на то, что это может сделать каждый тест «больше» по размеру, в целом это сделает тест более понятным, поскольку настройка специфична для каждого теста и целей каждого теста. Мне нравится этот совет, потому что я сталкивался со многими случаями, когда попытки сделать общие данные настройки делали вещи очень небрежными и очень быстрыми.