Соглашения об именах тестирования .NET

Я бы лично пошел с

Компания.Тесты.Сайт

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

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

Тесты.Компания.Сайт

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

Обычно в обозревателе решений я называю тестовые проекты Проект-тесты для краткости, а для пространств имен использую Company.Namespace.Tests.

Я большой поклонник такой структуры тестового пространства имен:

Company.Tests.Website.xxx

Company.Tests.Website.Controls

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

Я предпочитаю:

Компания.Сайт.Тесты

Меня не интересуют какие-либо подпространства имен, такие как Company.Website.Controls, все тесты входят в одно и то же пространство имен: Company.Website.Tests. Вы не хотите, чтобы ваши тестовые пространства имен ДОЛЖНЫ быть параллельными с остальной частью вашего кода, потому что это просто заставляет рефакторинг пространств имен занимать в два раза больше времени.

Я предпочитаю Company.Website.Spec и обычно имею один тестовый проект для каждого решения.

Мы следуем встроенному подходу:

Company.Namespace.Test
Company.Namespace.Data.Test

Таким образом, тесты близки к тестируемому коду, без необходимости переключаться между проектами или искать ссылки, чтобы убедиться, что существует тест, охватывающий конкретный метод. Нам также не нужно поддерживать две отдельные, но идентичные иерархии.

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

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

Я пойду с

* Company.Website - the project
* Company.Website.Tests

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

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

-Кодовая папка

• Вебсайт компании

-Папка тестов

• Компания.Сайт.Тесты

Я тоже предпочитаю ставить перед фактическим именем сборки префикс «Tests», чтобы было легко увидеть все мои сборки модульного теста, перечисленные вместе в алфавитном порядке, когда я массово выбираю их для загрузки в NUNit или любую другую тестовую систему, которую вы используете.

Итак, если бы веб-сайт был именем моего решения (и сборок), я предлагаю -

Tests.Website.dll вместе с фактической сборкой кода Website.Dll

Когда MVC стал реальностью в мире веб-разработки .net, я бы начал думать в этом направлении. Помните, что M, V и C - разные компоненты, поэтому:

• Company.Namespace.Website
• Company.Namespace.Website.Core
• Company.Namspance.Website.Core.Tests
• Company.Namespace.Website.Model
• Company.Namespace.Website.Model.Tests

Веб-сайт - это ваше легкое представление. Ядро содержит контроллеры, помощники, интерфейсы просмотра и т. д. Core.Tests - это ваши тесты для указанного ядра. Модель предназначена для вашей модели данных. Самое классное здесь то, что тесты вашей модели могут автоматизировать тесты, специфичные для вашей базы данных.

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