Тестирование реальных репозиториев

Question

Я настроил модульные тесты, которые тестируют поддельное хранилище и тесты, использующие поддельное хранилище.

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

Я что-то здесь упускаю?

Answer 1

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

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

Answer 2

Можете ли вы создать реальный репозиторий, который проверяет поддельную базу данных?

Независимо от того, что вы делаете, это является интеграционным тестированием, а не модульным тестированием.

Answer 3

Недавно я рассмотрел очень похожий вопрос здесь .

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

Answer 4

Я бы определенно предложил интеграционные тесты против DAL, в пределах разумного.

Мы не используем шаблон Repository как таковой (к нашему огорчению), но наша политика в отношении аналогичных классов (Searchers) следующая:

• Если метод выполняет простое извлечение из базы данных с использованием вызова O / RM, не проверяйте его.
• Если метод использует функции построения запросов O / RM, протестируйте его.
• Если метод содержит строку (например, имя столбца), протестируйте ее.
• Если метод вызывает хранимую процедуру, протестируйте ее.
• Если метод содержит логику, проверьте его. Но старайтесь избегать логики.
• Если метод обходит O / RM и использует необработанный SQL, протестируйте его. Но постарайся избежать этого.

Суть в том, что вы должны знать, что ваши O / RM работают (и, надеюсь, есть тесты), поэтому нет причин проверять базовое поведение CRUD.

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

РЕДАКТИРОВАТЬ: обратите внимание, что эти интеграционные тесты все еще будут тестировать ваш репозиторий в «изоляции» (за исключением базы данных). Все остальные ваши юнит-тесты будут использовать поддельный репозиторий.