Как делают Вас модульный тест класс, это предназначено, чтобы говорить с данными?
У меня есть несколько классов репозитория, которые предназначены, чтобы говорить с различными видами данных, происходящих из IRepository интерфейс.
В реализациях код говорит с источником данных, быть этим каталог XML-файлов или базы данных или даже просто кэша. Действительно ли это возможно к надежно модульному тесту какая-либо из этих реализаций? Я не вижу, что ложная реализация работает, потому что затем я только тестирую ложный код а не фактический код.
4 ответа
Нет, вы бы использовали макет при написании класса, который использует и IRepository . Для реализаций из IRepository вам нужно будет протестировать соответствующий источник данных. Для баз данных это немного неудобно, для файловой системы - немного меньше.
Если возможно, если вы можете выразить свою реализацию в терминах потоков или считывателей, вы упростите себе жизнь: тесты для этих частей реализации могут идти против источников данных в памяти или потоков из ресурсов в тестовой сборке. . Конечно, вам, вероятно, понадобится несколько тестов, которые обращаются к реальной базе данных или файловой системе, но, надеюсь, в меньшем количестве.
Назовете ли вы такие тесты «модульными» или нет, зависит от того, как вы определяете модульные тесты; лично меня не особо интересуют имена, но я действительно забочусь о прохождении тестов. В частности, для баз данных это может быть несколько болезненно (особенно если вы хотите иметь возможность запускать тесты параллельно), но, по моему опыту, они также могут быть невероятно ценными.
Я думаю, что если вы тестируете код, который на самом деле сохраняется, или запрашиваете данные, вы, вероятно, действительно хотите обратиться к базе данных.
Это интеграционные тесты, а не модульные тесты.
Вы можете создать тестовую базу данных, в которой вы знаете состояние данных, и запускать тесты для этого. Вы, вероятно, также захотите сообщить тестам, что они отличаются от ваших модульных тестов и что их не нужно запускать при каждой регистрации (в nUnit вы можете украсить свой тестовый класс атрибутом, запрещающим его запуск)
{{ 1}}В общем случае, вы не будете юнит тестировать любой код, единственной целью которого является общение с источником данных. Возможно, вы захотите автоматически тестировать хранилище, но такой тест будет интеграционным по определению. Вероятно, вы не захотите запускать эти тесты как часть "первого прохода" сборки, поскольку, например, настройка базы данных и уборка за собой может занять незначительное количество времени.
Если у вашего хранилища есть другие обязанности (например, реализация шаблона Unit of Work), то вы, возможно, захотите проводить модульное тестирование отдельно.
В какой-то момент реализации IRepository вы будете использовать сторонний API, который будет фактически читать/писать в/из базы данных/файла/xml. Вы захотите поиздеваться над этими API, чтобы убедиться, что ваш код вызывает нужные API в правильном порядке.
Так, если вы читаете из базы данных, вы можете сымитировать SqlConnection и SqlCommand и убедиться, что вы вызываете правильные методы этих классов. Если вы пишете в поток, вы можете высмеять поток и убедиться, что вы его промываете и утилизируете (например).