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

Question

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

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

EDIT: Я изначально отметил вопрос на разных языках, на которые, как я думал, это актуально, но, похоже, общий ответ на вопрос может быть «использовать тестовую структуру», которая является специфичной для языка. : D

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Если вы работаете с C#, тогда Visual Studio сделает это для вас, если вы выберете Test> New Test ... У этого есть мастер, который проведет вас через процесс.

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

Answer 9

В 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 

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

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

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

EDIT Обратите внимание, что Maven может создавать дистрибутивы без тестов, даже если они находятся в одном пакете. По умолчанию Maven также требует, чтобы все тесты проходили до развертывания проекта.

Answer 10

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

Например, я мог бы

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.