Действительно ли разумно осуществить это, модульные тесты никогда не должны говорить с живой базой данных/веб-сервисом?
Моя команда продолжает находить все больше значения в модульных тестах, которые мы пишем. Мы обычно не делаем, единица тестирует уровни доступа к данным наших приложений, поскольку они не содержат "логику". По моему опыту, мы столкнулись со значительными проблемами производительности и невоспроизводимыми ошибками в результате разрешения разработчикам записать модульные тесты, которые говорят для проживания баз данных (или веб-сервисы), и в результате все больше разработчиков создает насмешки, которые подают данные к этим модульным тестам.
Проявление этого подхода увеличило скорость тестов и изолировало тестирование к логике вместо того, чтобы тестировать соединение/извлечение одновременно. Я задаюсь вопросом, звучит ли это разумным для осуществления как стандарт кодирования. Что профессионалы/недостатки расценивают поблочное тестирование живые базы данных/веб-сервисы, которые я пропускаю?
7 ответов
Части вашего приложения, связанные с базой данных и веб-сервисом, также должны быть протестированы, но по определению это будут не модульные тесты, а интеграционные тесты. Эти тесты будут проводиться отдельно от ваших модульных тестов и выполняться реже, но обеспечат очень ценное раннее обнаружение дефектов.
Любой проверочный тест сборки должен быть как можно более полным. Если у вас есть вызов функции, который обращается к внешним ресурсам, вы должны убедиться, что вся система работает правильно.
Проблема с конкретными модульными тестами для функций, которые подключаются к базе данных, может быть проблематичной, потому что эти функции могут иметь побочные эффекты, такие как вставка данных. Эти побочные эффекты могут вызвать изменение возвращаемых значений.
По моему опыту, тестирование должно проводиться на нескольких уровнях:
- модульные тесты, которые проверяют правильность классов / модулей без необходимости во внешних данных
- системные тесты, которые проверяют более крупные части приложения, загружают данные из определенных баз данных / файлов и проверяют результаты (например, путем сравнения выходных файлов). Убедитесь, что вы не изменили эти базы данных / файлы и убедитесь, что у вас есть одна база данных / набор файлов на группу тестов
- ручных тестов, проверяющих пользовательский интерфейс
Каждый из этих тестов имеет свою полезность.
Мне очень жаль, но многие разработчики упускают из виду тот факт, что вам также необходимо провести модульное тестирование базы данных. Я могу согласиться с издевательством над соединением между классом «A» и базой данных, но в какой-то момент вы собираетесь создать класс, который использует некоторую технологию доступа к данным (например, ADO.NET), и вам нужно проверить это это действительно работает.
Теперь, если эти тесты будут небольшими и сфокусированными, вы сможете легче предотвратить побочные эффекты и обеспечить правильные начальные условия для базы данных. Но дело в том, что вы должны протестировать такой код, иначе ваша должным образом протестированная бизнес-логика окажется с неверными данными для работы.
Обычно я рассматриваю модульный тест как нечто, что тестирует отдельный класс или модуль изолированно . Поэтому я стараюсь избегать того, чтобы модульные тесты знали о действующих системах или внешних ресурсах - я стараюсь избегать таких зависимостей в модульных тестах - или имитировать их.
Интеграционные тесты - совсем другое дело. Интеграционный тест должен избегать имитации ресурсов, и, следовательно, может действительно потребоваться действующая база данных или сервис для его поддержки. То, что вы описываете, может быть скорее интеграционным, чем модульным.
В некоторых случаях желательно смоделировать сервисы, необходимые для интеграционного теста, но когда возможно, я стараюсь этого избегать, потому что я не верю, что моделирование может отражать поведение реальной вещи. Для меня интеграционный тест должен фактически проверить интеграцию компонентов в системе .
IMO Вам, вероятно, не хватает того, что, если вы используете базы данных / WS в тесте, это не модульный тест, а интеграционный тест.
Модульные тесты не должны выполняться с оперативными данными, точка.
Даже если вы хотите начать проводить интеграционные тесты, не начинайте это с живыми данными.
Начальное интеграционное тестирование всегда должно проводиться либо с данными разработчика, либо с данными макета. Предпочтительным методом было бы иметь систему разработки, которая публикует данные в реальном времени, или использовать сценарии sql для генерации полного набора данных, которые вы можете проверить.