где я должен поставить свой тестовый код для моего класса?

Question

Итак, я написал класс, и у меня есть код для его тестирования, но куда мне поместить этот код? Я мог бы сделать статический метод Test () для класса, но он не должен быть там во время производства и загромождает объявление класса. Немного поиска подсказало мне поместить тестовый код в отдельный проект, но каким именно будет формат этого проекта? Один статический класс с методом для каждого из классов, поэтому, если бы мой класс назывался Randomizer, метод назывался бы testRandomizer?

Каковы некоторые рекомендации по организации тестового кода?

РЕДАКТИРОВАТЬ: Первоначально я пометил вопрос с различными языками, для которых я думал, что он имеет отношение, но кажется, что общий ответ на вопрос может быть «использовать рамки тестирования», который зависит от языка. : D

Answer 1

Независимо от того, используете ли вы тестовую среду (я настоятельно рекомендую это сделать) или нет, лучшее место для модульных тестов - отдельная сборка (C / C ++ / C #) или пакет (Java).

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

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

Формат проекта зависит от тестовой среды - для тестового проекта .NET используйте VS, встроенные в шаблон тестового проекта, или NUnit в вашей версии VS не поддерживает модульное тестирование, для Java используйте JUnit, для C / C ++, возможно, CppUnit (я еще не пробовал).

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

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

Answer 2

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

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

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

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

Answer 3

В Java вы должны использовать Junit4, либо сам по себе, либо (я думаю, лучше) с IDE. Мы использовали три среды: Eclipse, NetBeans и Maven (с IDE и без). Между ними могут быть небольшие несовместимости, если они не используются систематически.

Как правило, все тесты находятся в одном проекте, но в другой папке / папке. Таким образом, класс:

org.foo.Bar.java

будет иметь тест

org.foo.BarTest.java

Они находятся в одном пакете (org.foo), но будут организованы в каталогах:

src/main/java/org/foo/Bar.java 

и

src/test/java/org/foo/BarTest.java 

Эти каталоги общепризнаны в Eclipse, NetBeans и Maven. Maven самый требовательный, тогда как Eclipse не всегда соблюдает строгость.

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

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

РЕДАКТИРОВАТЬ Обратите внимание, что Maven может создавать дистрибутивы без тестов, даже если они находятся в одном пакете. По умолчанию Maven также требует, чтобы все тесты были пройдены до развертывания проекта.

Answer 4

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

Например, у меня может быть

myproject
    src
        main
            com.acme.myapp.model
                User
            com.acme.myapp.web
                RegisterController
        test
            com.acme.myapp.model
                UserTest
            com.acme.myapp.web
                RegisterControllerTest

Maven делает это, но подход не особенно привязан к Maven.

Answer 5

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

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

Answer 6

Создание отдельных проектов для юнит-тестов, интеграционных и функциональных тестов. Даже если в вашем «реальном» коде есть несколько проектов, вы, вероятно, можете сделать с одним проектом для каждого типа теста, но важно различать каждый тип теста.

Для юнит-тестов вы должны создать параллельную иерархию пространства имен. Поэтому, если у вас есть crazy.juggler.drummer.Customer, вам следует выполнить его юнит-тестирование в crazy.juggler.drummer.CustomerTest. Таким образом, легко увидеть, какие классы правильно протестированы.

Функциональные и интеграционные тесты могут быть сложнее, но обычно вы можете найти подходящее место. Тесты уровня базы данных, вероятно, принадлежат где-то вроде my.app.database.DatabaseIntegrationTest. Функциональные тесты могут гарантировать свое собственное пространство имен: my.app.functionaltests.CustomerCreationWorkflowTest.

Но совет № 1: будьте внимательны при разделении различных видов тестов. Особенно убедитесь, что коллекция юнит-тестов отделена от интеграционных тестов.

Answer 7

В случае C # и Visual Studio 2010 вы можете создать тестовый проект из шаблонов , который будет включен в решение вашего проекта. Затем вы сможете указать, какие тесты проводить при построении вашего проекта. Все тесты будут жить в отдельной сборке.

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

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

Answer 8

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

Answer 9

Создайте новый проект в том же решении, что и ваш код.

Если вы работаете с c #, Visual Studio сделает это за вас, если вы выберете Тест> Новый тест ... У него есть мастер, который проведет вас через процесс.

Answer 10

Это будет зависеть от используемой вами среды тестирования. JUnit, NUnit, некоторые другие? Каждый из них документирует свой способ организации тестового кода. Кроме того, если вы используете непрерывную интеграцию, это также повлияет на то, где и как вы разместите свой тест. Например, В этой статье обсуждаются некоторые варианты.