В настоящее время я разделяю все свои тесты по пакетам (проектам). Поэтому, если у меня есть 12 проектов, я создам еще один проект для Unit Test с 12 классами, которые будут проверять весь мой пакет.
Вы делаете то же самое или у вас есть 1 класс тестирования по классам? Как вы организуете все свои тесты?
Как и у Pokus, мои тесты находятся в той же сборке, что и классы для тестирования, поэтому я могу тестировать внутренние и частные лица.
В С# у вас есть сборки Debug и Release, я добавляю еще один модуль UnitTest с директивой компилятора UNITTEST. Затем я могу добавить директиву (#if UNITTEST) в верхней части тестового класса, чтобы при компиляции Debug или Release тесты не были скомпилированы, но когда я компилирую UnitTest, они есть.
Я добавляю папку под названием Tests, которая содержит мои тестовые классы. Класс1.cs имеет тестовый класс Tests\Class1UnitTest.cs.
Может быть, лучше, но это работает для меня.
В настройке Java/Maven:
project/src/main/java/Package/Class.java
project/src/test/java/Package/ClassTest.java
project/src/main/resources/Package/resource.properties
project/src/test/resources/Package/test_resource.properties
Поскольку я, как правило, занимаюсь TDD, у меня есть тестовый класс для каждого класса и группируйте эти тестовые классы в прямой для одного соответствия тестового проекта реальному проекту. В зависимости от размера решения тестовые проекты либо существуют в одном и том же решении (если они небольшие), либо разбиваются на отдельные решения (если они больше)
Мы организовали это так (С++):
package/Class.cpp
package/Class.hpp
package/test/ClassUnitTest.cpp
package/test/ClassIntegrationTest.cpp
test/unit-test/main.cpp
test/integration-test/main.cpp
test/data
test/tmp
Где unit тест и интеграционный тест - это только те, кто тестирует, тестовые/данные хранят файлы данных, которые используются интеграционными тестами, и test/tmp содержит временные файлы, созданные теми же тестами, и очищается для каждого набора тестов.
Я сохраняю свои модульные тесты в пакете в рамках тестируемого проекта. Таким образом, все тесты проверяются с помощью управления версиями с помощью кода приложения. Каталог unit test в основном является зеркалом исходного каталога, так что структура пакета идентична между двумя.
В качестве примера (не мои настоящие имена пакетов):
src.com.app
src.com.app.model
src.com.app.view
src.com.app.controller
tests.com.app
tests.com.app.model
tests.com.app.view
tests.com.app.controller
У меня есть мой тестовый класс в моем проекте, где класс. Таким образом, я могу протестировать внутренние вещи. Я добавляю postfix "Test" к имени класса. Пример: MyClass.cs будет MyClassTest.cs
Мне нравится, чтобы мои src и тесты существовали в одном пакете. Поэтому я организую шахту следующим образом:
src/com/company/package/Class.java
testsrc/com/company/package/ClassTest.java
Я держу их в отдельном пакете для всего продукта. Мне не нравится загромождать производственный код кодом unit test.
Company/Product/Package1 Company/Product/PackageN Company/Product/UnitTest/Package1/Class/Method1Fixture.cs Company/Product/UnitTest/Package1/Class/MethodNFixture.cs Company/Product/UnitTest/PackageN/Class/Method1Fixture.cs Company/Product/UnitTest/PackageN/Class/MethodNFixture.cs
Все мои методы объявлены публичными виртуальными, я тоже много издеваюсь. Конечно, это в основном связано с тем, что, как правило, пакеты, которые я тестирую, являются бизнес-логикой и слоями данных, поэтому они редко имеют какие-либо истинные внутренние методы. Но у меня есть несколько проектов, которые имеют "внутренние" методы. Для них, если они являются внутренним балансом компании, то использование общедоступных для всех методов не является проблемой. Я считаю, что если вы не хотите, чтобы все методы были общедоступными, вы можете использовать узлы с жесткими именами и настроить их таким образом, чтобы сборка unit test могла получить доступ к внутренним методам. В конце я имею единственную сборку unit test, которая будет содержать все тестовые приборы для всего проекта.
Мы выполняем индивидуальные тестовые сборки (С#). Для каждой сборки в решении у нас есть соответствующий тестовый проект. Каждый проект имеет тест для каждого класса в соответствующем проекте.
Например:
Company.Product.Feature
ClassnameAlpha
ClassnameBeta
ClassnameDelta
Company.Product.Feature.UnitTests
ClassnameAlphaTests
ClassnameBetaTests
ClassnameDeltaTests
Я принимаю то, что xando делает немного дальше. Вместо использования конфигураций Debug/Release по умолчанию у меня есть конфигурация для каждой из ветвей, которые мы используем для конфигураций сборки в Team Foundation Server. Итак, у меня есть Development, Integration и Production. Не вдаваясь в задумчиво скучные особенности, модульные тесты построены для конфигураций разработки и интеграции. Они включены в производственную отрасль, но не скомпилированы с помощью сборки. Причина, по которой они включены, заключается в том, что когда нам нужно отделить производство (например, исправление), модульные тесты могут запускаться, модифицироваться и реверсивно интегрироваться с измененным кодом.
В настоящее время у нас есть только небольшое подразделение команды, использующее это прямо сейчас, так как мы находимся в процессе перехода от устаревшей системы управления версиями и версиями, но пока это хорошо работает. На данный момент особенность его тестирования особенно хорошо работает.
Мне нравится держать их ближе к коду, которые они поддерживают, как правило, в отдельном подкаталоге. Таким образом, я могу их компилировать с кодом, что делает их видимыми - это важно, это устаревшие проекты, когда только некоторые из компонентов имеют модульные тесты.
.../component/src/
/include/
/doc/
/bin/
/test/
Обычно у нас есть один набор на двоичный код, но у него есть исключения. Мы можем запускать все тесты в любом каталоге с помощью простой команды.
Эмпирическое правило состоит в том, чтобы простые тесты легко находить, легко компилировать и легко запускать, чтобы они не попадали в одну сторону.
У меня есть мой тест, организованный категорией теста. Если есть все мои файлы unit test в 1 каталоге. Вся интеграция в 1 каталоге. У меня есть все тесты на постоянство в другом. Все папки имеют много файлов для каждой подобной вещи для проверки.