прикладные уровни модульного тестирования

Question

У меня есть трехуровневое приложение с уровнями доступа к данным, обслуживания и представления.Где я должен разместить юнит-тесты?На каждом слое?один слой презентации?

Answer 1

Как правило, вы используете модульные тесты - если вы думаете, что JUnit, NUnit и т. Д. - для небольших изолированных частей вашего кода, в идеале для отдельных классов (не всегда так работает, и поэтому кто-то изобрел ложные выражения).

Из трех упомянутых вами слоев вы можете найти этот тип теста во всех трех из них.При правильном дизайне (например, MVC) вы можете протестировать даже большие части уровня представления.При тестировании уровня обслуживания или уровня домена (= бизнес-логика) это помогает имитировать уровень доступа к данным.При тестировании уровня доступа к данным попробуйте использовать базу данных в оперативной памяти для скорости или использовать готовый инструмент ORM (Object-Relational Mapping).

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

Answer 2

Отчасти это зависит от вашего подхода. Если у вас уже есть код на месте, и вы создаете модульные тесты после создания кода - я бы начал с добавления некоторых окончательных приемочных тестов. Это будет осуществлять все слои.

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

В зависимости от того, насколько у вас ограничен доступ к данным, я бы не стал писать здесь какие-либо модульные тесты, поскольку ошибки следует подбирать довольно эффективно, без необходимости их модульного тестирования.

Если вы начинаете с нуля, прочитайте BDD / TDD и используйте этот подход для обеспечения качества.

Answer 3

Я собирался ответить «каждый слой, вы не можете иметь слишком много тестового кода», но это не обязательно так.

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

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

Answer 4

Где разместить тесты?

Честно говоря, везде.

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

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

Answer 5

Как правило, все промежуточные тесты выполняются на среднем уровне.

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