У меня есть трехуровневое приложение с уровнями доступа к данным, обслуживания и представления. Где я должен размещать модульные тесты? На каждом слое? один слой презентации?уровни тестирования тестирования модулей
Некоторые из этих факторов зависят от подхода. Если у вас уже есть код на месте, и после создания кода вы проводите модульные тесты, я бы начал с добавления некоторых тестов приемочного тестирования. Это будет использовать все слои.
Затем, когда вы вносите изменения в какую-либо часть системы, я начинаю сдавать модульные тесты вокруг изменяемого компонента - сначала просто тестируем существующую функциональность, а затем переходим к добавлению модульных тестов для новых функций. Это хорошо работает, если вы код слабо связан и разделен на четко определенные компоненты. Если нет, у вас много работы.
В зависимости от того, насколько тонкий ваш доступ к данным, я был бы менее склонен писать какие-либо юнит-тесты здесь, так как ошибки следует брать довольно рентабельным образом, не подвергая их тестированию.
Если вы начинаете свежие, прочтите BDD/TDD и используйте этот подход для обеспечения качества.
Обычно у вас будут все ваши юнит-тесты в среднем ярусе.
У вас могут быть интеграционные тесты в DAL и ручное или автоматическое тестирование интерфейса этого слоя. Если вы найдете части этих слоев, которые могут быть проверены модулем, то, во всяком случае, делайте это - хотя вы должны также задать вопрос, должны ли они быть в этих слоях в этом случае.
Как правило, вы должны использовать модульные тесты, считая, что вы думаете, что JUnit, NUnit и т. Д. - для небольших изолированных частей вашего кода, в идеале одиночные классы (не всегда так работают, и именно поэтому кто-то изобрел mocks).
Из трех слоев, о которых вы упоминаете, вы можете найти этот тип теста во всех трех из них. При правильной конструкции (например, MVC) вы можете протестировать даже большие части уровня представления. При тестировании уровня обслуживания или уровня домена (= бизнес-логика) это помогает высмеять уровень доступа к данным. При тестировании уровня доступа к данным попробуйте использовать базу данных в памяти для скорости или используйте встроенный инструмент ORM (Object-Relational Mapping) в первую очередь.
В целом я бы рекомендовал использовать модульные тесты щедро, везде, где они обеспечивают ценность. Большинство команд разработчиков не рискуют писать слишком много модульных тестов. Но также имейте в виду, что модульные тесты - это всего лишь один аспект, и другие типы тестов и/или инструменты могут быть лучше подходят.
Не уверен, что я на 100% согласен с последним абзацем. Я видел, что слишком много людей зацикливаются на модуле тестирования уровня презентации - или стремятся к 100% -ному охвату. Они идут вверх по кривой убывающей отдачи. Тестирование - это хорошо. Но, как и все, что вы, конечно, можете * получить слишком много хорошего. – philsquared
Где я могу поместить модульные тесты?
Откровенно говоря, везде.
Если возможно, каждый кусок кода, который вы пишете, должен иметь автоматическую проверку. Если вы идете на объектно-ориентированный подход, каждый объект должен иметь набор модульных тестов. Если ваша программа является процедурной, каждая функция должна иметь модульные тесты, которые ее используют.
Просто убедитесь, что тесты вашего устройства работают достаточно быстро, чтобы другие разработчики не прочь использовать их.
Я собирался ответить «каждый слой, у вас не может быть слишком много тестового кода», но это не обязательно так.
Я должен был сказать, что это зависит от того, насколько плотно связаны слои.Если вы можете получить полный охват, используя только верхний слой, который идеален в любом случае, вы бы не имели, чтобы создать отдельные тесты для нижних слоев.
Если нет, например, если уровень доступа к данным является общей библиотекой, которая только частично используется на данный момент, вы, по крайней мере, добавили бы тесты на этом уровне, чтобы получить покрытие и быть более уверенным в том, есть проблемы, которые появятся позже.
Я не уверен насчет «всех ... единичных тестов в среднем ярусе». Например, в MVC-дизайне (например, RoR, ASP.NET MVC и т. Д.) Вы можете написать модульные тесты для контроллеров, которые я буду считать частью уровня представления. В равной степени уровень доступа к базе данных - если он разработан в доме - вероятно, будет разработан с помощью тестовых тестов с модульными тестами. Я согласен, однако, что обычно уровень с бизнес-логикой часто имеет наибольшую долю единичных тестов. – Manfred
@John Семантика, я думаю. Когда я думаю о слое представления, я думаю о представлениях - и DAL = Model. Поэтому контроллеры являются средним уровнем. В контексте веб-архитектуры я понимаю, что термины используются в другом масштабе. – philsquared
Согласен. Это зависит от архитектуры системы, чтобы решить, какой тип тестирования наиболее подходит для какого слоя. – Manfred