Каковы наилучшие соглашения об именовании тестовых сборок в .NET(или на любом другом языке или платформе)?
В основном я разделяю эти параметры (просьба указать других!):
или
Проблема с первым решением заключается в том, что он выглядит как .Tests - это пространство под-имен для сайта, в то время как они действительно более параллельны в моем сознании. Что происходит, когда вступает в игру новое пространство подзаголовков, например Company.Website.Controls, где я должен поставить тесты для этого пространства имен, например?
Может быть, это даже должно быть: Tests.Company.Website и Tests.Company.Website.Controls и т.д.
Пойду с
* Company.Website - the project
* Company.Website.Tests
Краткая причина и ответ просты, тестирование и проект связаны в коде, поэтому он должен разделять пространство имен.
Если вы хотите разделить код и тестирование в решении, у вас есть такая опция. например вы можете настроить решение с помощью
-Кодовая папка
-Tests Folder
Я лично пошел бы с
Company.Tests.Website
Таким образом, у вас есть общее пространство имен тестов и проекты внутри него, следуя той же структуре, что и фактический проект.
На самом деле у меня есть альтернативный параллельный корень.
Tests.Company.Website
Он отлично работает для устранения неоднозначности вещей, когда у вас есть новые подпространства имен.
Я большой поклонник структурирования тестового пространства имен следующим образом:
Company.Tests.Website.xxx
Company.Tests.Website.Controls
Как и вы, я считаю, что тесты как параллельная структура пространства имен для основного кода, и это дает вам это. Это также имеет то преимущество, что, поскольку пространство имен все еще начинается с названия вашей компании, у вас не должно быть никаких коллизий именования с сторонними библиотеками.
Я также предпочитаю "Тесты", префиксное фактическое имя сборки, чтобы было легко увидеть все мои сборки unit test, перечисленные в алфавитном порядке вместе, когда я массово выбираю их, чтобы втянуть NUNit или какую-либо тестовую проводку, которую вы используете.
Итак, если сайт был именем моего решения (и сборок), я предлагаю -
Tests.Website.dll, чтобы идти вместе с фактической сборкой кода Website.Dll
Я обычно называю тестовые проекты Project-Tests для краткости в обозревателе решений, и я использую System.Namespace.Tests для пространств имен.
Я предпочитаю идти с:
Company.Website.Tests
Мне не нужны никакие подпространства имен, такие как Company.Website.Controls, все тесты входят в одно и то же пространство имен: Company.Website.Tests. Вы не хотите, чтобы ваши тестовые пространства имен были в Parrallel с остальной частью вашего кода, потому что он просто делает рефакторинг пространств имен в два раза длиннее.
Я предпочитаю Company.Website.Spec и обычно имеет один тестовый проект на решение
Мы следуем встроенному подходу:
Company.Namespace.Test
Company.Namespace.Data.Test
Таким образом, тесты близки к тестируемому коду, без необходимости переключаться между проектами или выслеживать ссылки, чтобы гарантировать, что существует тест, охватывающий конкретный метод. Нам также не нужно поддерживать две отдельные, но идентичные иерархии.
Мы также можем тестировать отдельные части кода по мере расширения и развития.
Сначала кажется немного странным, но в долгосрочной перспективе это сработало очень хорошо для нас.
Когда MVC начинает становиться реальностью в мире веб-разработки .net, я бы начал думать в этом направлении. Помните, что M, V и C являются отдельными компонентами, поэтому:
Сайт - ваш легкий вид. Core содержит контроллеры, помощники, интерфейсы представления и т.д. Core.Tests - это ваши тесты для упомянутого Core. Модель предназначена для вашей модели данных. Приятная вещь здесь в том, что ваши тесты модели могут автоматизировать ваши тесты, специфичные для базы данных.
Это может быть излишним для некоторых людей, но я считаю, что это позволяет мне довольно легко отделять проблемы.