Неправильно ли применять тестовый метод JUnit в тестируемый класс?

Question

Рассмотрим класс Java с небольшими статическими методами в стиле библиотеки.

Неправильно ли применять методы тестирования JUnit в одном классе?

Я вижу следующие плюсы: тест

• JUnit как самодокументирование находится в непосредственной близости от метода кода
• будет легко перенести этот код в другой класс или пакет

Каковы контрасты, и почему это общая практика, чтобы всегда отделять тестовый код?

Пример:

import org.junit.*; 

public class HtmlUtils { 
    public static String normalizeBrs(String html) { 
     return html.replaceAll("<br\\s*/?>", "<br/>"); 
    } 

    @Test 
    public void testNormalizeBrs() { 
     Assert.assertEquals(normalizeBrs("hello <br /> world <br>"), "hello <br/> world <br/>"); 
    } 
} 

Answer 1

вы можете не заметить никакой разницы, если ваш пакет мал.

Но представьте, что у вас есть пакет, содержащий 1000 классов, а затем 10 тысяч методов. что означает 10 тысяч тысяч тестов.

так что произойдет, если все коды + тесты вместе?

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

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

Answer 2

Мы сохраняем исходный код отдельно от тестового кода.

Вот причины, которые я знаю.

1. Мы создаем сборку исходного кода для производства и не должны содержать тестовый код. Ненужное увеличение размера кода.
2. Отдельный тестовый проект помогает. Чтобы мы могли запускать тестовую сборку через регулярные интервалы с источником, чтобы проверить, все ли проверено. например Общая практика заключается в том, что при изменении кода и нажатии кода эти тестовые сборки запускаются, а затем ваши новые изменения проверяются на него.
3. Тестовые чехлы предназначены только для внутреннего использования, чтобы гарантировать качество кода. Большинство клиентов не заинтересованы в нем.

Не стесняйтесь добавлять в этом списке.

Cheers !!!

Answer 3

В дополнение к ответу NAFAS

Keep тесты в том же месте, что и исходный код

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

http://www.javaworld.com/article/2076265/testing-debugging/junit-best-practices.html http://www.kyleblaney.com/junit-best-practices/

Answer 4

(Это плохая практика поставить метод испытания JUnit в тестируемом классе?)

Абсолютно.

Основная причина здесь: single responsibility principle. Класс, метод, любой вещь в программировании должен поддерживать/обеспечивать точно один ответственность.

Основная ответственность вашего производственного кода - выполнить его «производственную цель».

Иными словами: бизнес-логика - это бизнес-логика. Nothing Остальные.

Все, что не принадлежит в этом ведре ... идет где еще.

Тестирование - это «вещь», аспект, ответственность, однако вы называете это.

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

Когда ваш производственный класс x.y.Z ... тогда класс испытания будет x.y.ZTest; но, хотя они находятся в одном пакете, вы обычно размещаете их в разные папки источника.

И кроме того: рефакторинга для Явы можно рассматривать как «решенную проблему» в 2017. Перемещение методов в различные классы, или изменении имен пакетов так легко сегодня, что вы (абсолютно) не нужно беспокоиться об этом. (если рефакторинг выглядит настолько опасным для вас, что вы считаете, что загрязняете свой производственный код тестовым кодом, то хорошо: научитесь использовать современные инструменты дня)

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

Answer 5

Одна из проверенных и проверенных моделей - это то, что используется стандартной планировкой проекта Maven и многими другими структурами сборки.

У нас есть отдельные каталоги src/main и src/test, но они оба находятся в одном проекте.

src/main содержит весь производственный код и ничего больше.

src/test содержит модульные тесты.

Конфигурация сборки определяет зависимости и знает разницу между классами тестов и производственными классами.

Для тестирования требуются некоторые зависимости. Наиболее принципиально, jUnit себя.Также думает, как насмешливые библиотеки (JMock, Mockito), такие утилиты, как Hamcrest, такие инструменты, как WireMock или RestClientDriver, собственные тестовые библиотеки и т. Д.

Эти библиотеки не нужны для запуска вашего производственного кода, поэтому вы должны 't связывает их в сборке, а также не объявляет их как зависимости.

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

Maven ставит тестовые зависимости в пути к классам при компиляции и запуске тестов, но не помещает их в путь класса при компиляции производственного кода. Это означает, что если вы попытаетесь использовать jUnit, Mockito и т. Д. В производственном классе, вы получите ошибку компиляции - это то, что вы хотите.

Итак:

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

Все это также имеет то преимущество, что программисты Java, как правило, знакомы с этим макетом. Программистам нравится не удивляться.

Ваши замечания:

• «JUnit тест как самодокументирования прямо возле кода метода»

Это верное наблюдение, и есть некоторый прецедент для написания тестов рядный по этой причине. Однако он, как правило, был в средах, где размер распределенного кода не имел значения, или где было средство для извлечения или игнорирования тестового кода как части сборки. Например, в C тесты могут быть в директиве препроцессора #IFDEF TEST. Это связано с тем, что при удалении «тестового» кода вы удаляете что-то, что действительно необходимо для работы программного обеспечения, то есть код, который работает только при наличии тестового кода!

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

• «Будет легко перенести этот код в другой класс или пакет»

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

-

Моя рекомендация состоит в том, что вы принимаете эти устоявшиеся практики, будь то с помощью Maven, Gradle или какой-либо другой системы сборки.

Answer 6

Если у вас есть тесты в коде производства, а затем:

1. вы будете иметь дополнительные зависимости (и, следовательно, больший размер файла банку/война/уха, больше времени для загрузки, больше RESSOURCES памяти нужен) для вашего производственного кода (например, Mockito, ...), который абсолютно не нужен для запуска приложения
2. , у вас будут дополнительные атрибуты внутри вашего класса, которые нужны для ресурсов памяти и, возможно, противоречат атрибутам вашего приложения атрибуты
3. методы тестирования должны быть общедоступными, поэтому методы тестирования являются частью ap i вашего производственного кода (который совершенно путается для людей, желающих использовать ваш код приложения)
4. классы становятся все длиннее и сложнее в обслуживании
5. Вы нарушаете конвенции, например. of maven