Один или несколько проектов Unit Test для каждого решения?

Я обычно имел сопоставление 1:1 между моими сборками продуктов и моими сборками unit test. Обычно я стараюсь, чтобы общее количество сборок было низким, и типичное решение может выглядеть примерно так...

Клиент (содержит представления, контроллеры и т.д.)
Client.Tests
Общий (содержит контракты на данные/обслуживание, общие утилиты и т.д.)
Common.Tests
Сервер (содержит домен, услуги и т.д.)
Server.Tests
Server.WebHost

В последнее время на работе люди упоминают, что у него есть только один проект unit test, и он разбивает их на сборку, которую они тестируют. Я знаю в тот же день, это облегчило жизнь, если вы выполняли NCover и т.д. Как часть вашей сборки (теперь, конечно, не вопрос).

Каково общее рациональное отношение к одиночным или нескольким проектам UnitTest? Есть ли какая-то конкретная причина идти так или иначе, кроме сокращения количества проектов в решении? У меня создается впечатление, что это может быть одним из тех "предпочтений", но Googling не очень много.

Ответ 1

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

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

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

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

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

На мой взгляд, группировка вещей, когда их слишком много, не обязательно хорошая вещь. Это может быть, но я считаю, что в контексте этой дискуссии это неправильный аргумент для одного тестового проекта. Слишком много тестовых проектов со многими файлами внутри означает только один с большим количеством тестовых файлов. Я считаю, что реальная проблема заключается в том, что решение, над которым вы работаете, становится большим. Возможно, есть другие вещи, которые вы можете сделать, чтобы избежать "одного мира"?:)

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Опять же, я думаю, что это предпочтение, я никогда не слышал определенного урегулирования так или иначе, но есть мои две центы...

Ответ 5

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