Как вы тестируете модуль, предназначенный для общения с данными?

Question

У меня есть несколько классов репозитория, предназначенных для общения с различными видами данных, происходящими из интерфейса IRepository.

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

Answer 1

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

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

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

Answer 2

В какой-то момент в реализации IRepository вы будете использовать сторонний API, который фактически будет читать / записывать в / из базы данных / файла / xml. То, что вы хотите сделать - это смоделировать эти API, чтобы убедиться, что ваш код вызывает правильный API в правильном порядке.

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

Answer 3

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

Если в вашем хранилище есть другие обязанности (например, реализация шаблона «Единица работы»), то вы можете захотеть выполнить их модульное тестирование отдельно.

Answer 4

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

Это интеграционные тесты, а не модульные тесты.

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