Лучшие практики для структурирования проектов тестирования Visual Studio

Question

Я знаю, что нет правильного или неправильного ответа на это, но было бы ОЧЕНЬ полезно увидеть, как другие структурировали свои тестовые проекты? Специально для многосборных решений и управления различными этапами тестирования, модулем, интеграцией, системой?

И вдобавок ко всему было бы полезно посмотреть, какая структура отлично подходит для запуска тестовых сборок на сервере непрерывной интеграции (TeamCity)?

Изначально я начинаю с:

Test (Namespace)
--Unit (Folder)
----ClassATests 
----ClassBTests
--Integration (Folder)
----ClassA+BTests 
----DBTests

Answer 1

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

В попытке упростить дело я начал использовать следующую структуру:

Tests (Namespace)
-- Infrastructure (Folder)
---- general utility classes (common to all tests)
---- any other config
-- ClassATests (Folder)
---- ClassATestBase (base class for setup of common mock objects etc.)
---- ClassATestMethods (helper methods for the ClassATests)
---- ClassATests (main test class)
-- ClassBTests (Folder)
etc.

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

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

Answer 2

Я храню свои модульные тесты и интеграционные тесты в отдельных сборках (x.Tests.dll, y.IntegrationTests.dll), чтобы можно было легко находить тестовые сборки для запуска в процессе сборки. Затем я могу просто найти * .Tests.dll и запускать их как часть ежедневной сборки. Интеграционные тесты запускаются вручную в определенных средах, но все еще могут запускаться из простого сценария сборки.

Кроме того, TestClass-per-Class является в значительной степени правилом, которому я следовал, за исключением небольших вспомогательных классов, которые все тестируются из одного приспособления HelperTests.