Зачем мне делать UnitTest для моего SQL, DAL и BLL, если мое приложение будет вызывать только методы BLL?

Question

Я провел несколько тестов, используя интегрированную среду тестирования VisualStudio, они симулируют то, что будет делать мое веб-приложение, вызывая методы BLL (они только те, с которыми пользовательский интерфейс должен знать и взаимодействовать) ...

Так что, если их поведение правильное - я сдаю тесты - зачем Я пишу тесты для нижних уровней, таких как DAL / Хранимые процедуры, так много литература предлагает мне сделать?

Answer 1

Сквозное тестирование хорошо и гарантирует, что ваше приложение работает для определенных сценариев.

Миско Хевери поместил хорошую запись в блоге по категоризации теста , где он разбивает юнит-тест, интеграционный тест и сквозное тестирование.

Unit-тестирование Модульное тестирование проверяет, что логика в этом методе функции работает правильно и что обработка ошибок выполняется правильно. Эти тесты в идеале должны выполняться за миллисекунды, а не секунды. Если функция должна взаимодействовать с чем-то, например, с DAL, вам следует смоделировать этот интерфейс DAL, поскольку для истинного взаимодействия потребуется много времени. Они предлагают лучший возврат инвестиций

Интеграционное тестирование Этот уровень тестирования проверяет, что взаимодействие между слоями Business Logic делает именно то, что они должны делать. Здесь ваш модульный тест будет взаимодействовать с интерфейсом, таким как DAL, и проверять правильность «проводки». Их должно быть несколько, но не слишком много, так как это повлияет на время сборки

Сквозное тестирование Это хорошо, поскольку они проверяют, что все соединяется от пользовательского интерфейса вплоть до DAL. Они проверяют намного больше «проводки» и проверяют, что то, что может сделать ваш пользователь, не убьет ваше приложение. Они также могут включать ваши FitNesse и веб-тесты, такие как Selenium , проходящие.

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

Answer 2

Выступая с фоном NUnit

Тестирование SP / доступа к данным не так легко сделать. Вы должны убедиться, что у вас есть «чистая» база данных при каждом запуске тестов, с ожидаемыми данными в начале, чтобы гарантировать получение ожидаемых результатов. Поэтому вам нужно либо каждый раз восстанавливать БД из чистой резервной копии, либо убедиться, что ваши тесты устанавливают базу данных с данными, которые ей необходимы, перед началом тестов.

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

Мое личное мнение таково, что мне нравится использовать комбинацию mocking и фактического доступа к БД в моих модульных тестах, так как я хотел бы знать, что мой код будет работать так, как ожидалось, до и из БД, чтобы ловить глупости ошибки, такие как отсутствие / ошибки SP (граница между тестами модулей / интеграции / функциональности). Но там, где это не так важно, я использую издевательства.