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

Каковы наилучшие соглашения об именовании тестовых сборок в .NET(или на любом другом языке или платформе)?

В основном я разделяю эти параметры (просьба указать других!):

  • Компания. Веб-сайт - проект
  • Company.Website.Tests

или

  • Company.Website
  • Company.WebsiteTests

Проблема с первым решением заключается в том, что он выглядит как .Tests - это пространство под-имен для сайта, в то время как они действительно более параллельны в моем сознании. Что происходит, когда вступает в игру новое пространство подзаголовков, например Company.Website.Controls, где я должен поставить тесты для этого пространства имен, например?

Может быть, это даже должно быть: Tests.Company.Website и Tests.Company.Website.Controls и т.д.

ОТВЕТЫ

Ответ 1

Пойду с

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

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

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

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

  • Company.Website

-Tests Folder

  • Company.Website.Tests

Ответ 2

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

Company.Tests.Website

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

Ответ 3

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

Tests.Company.Website

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

Ответ 4

Я большой поклонник структурирования тестового пространства имен следующим образом:

Company.Tests.Website.xxx

Company.Tests.Website.Controls

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

Ответ 5

Я также предпочитаю "Тесты", префиксное фактическое имя сборки, чтобы было легко увидеть все мои сборки unit test, перечисленные в алфавитном порядке вместе, когда я массово выбираю их, чтобы втянуть NUNit или какую-либо тестовую проводку, которую вы используете.

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

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

Ответ 6

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

Ответ 7

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

Company.Website.Tests

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

Ответ 8

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

Ответ 9

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

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

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

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

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

Ответ 10

Когда 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 содержит контроллеры, помощники, интерфейсы представления и т.д. Core.Tests - это ваши тесты для упомянутого Core. Модель предназначена для вашей модели данных. Приятная вещь здесь в том, что ваши тесты модели могут автоматизировать ваши тесты, специфичные для базы данных.

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