Привычки Java для основного метода

Question

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

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

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

РЕДАКТИРОВАТЬ: Чтобы играть адвоката дьявола (хорошо, мой адвокат) относительно некоторых из предложенных ответов: ожидается, что частью «использования приложения» будет изменение источника не разработчиками (типичным ученым) в небольшом масштабе. Я знаю, что на стороне получателя, что наличие тестов для класса, встроенного непосредственно в этот класс, было бы для меня довольно простым для распознавания и изменения соответствующим образом (особенно, если это было последовательно для классов). Будет ли использование чего-то вроде JUnit обеспечивать аналогичную утилиту с учетом аудитории?

ПРИНЯТЬ РЕШЕНИЕ: Я думаю, что ответ KLE - лучший баланс тщательности и краткости, поэтому я выбрал его, но я думаю, что комментарии к обсуждению в Билле также очень полезны. Я также не понимаю, почему ответ Йоханнеса был отклонен - ​​перспектива «как работает эта часть» очень важна для программистов научного сообщества - и в то время как другие ответы указывают на различные причины, почему отдельные модульные тесты, вероятно, более полезны, чем мои В настоящее время они не обращаются к этому использованию, поэтому его ответ далеко не бесполезен. Спасибо всем нынешним (и будущим) респондентам, и вот желающим был способ объединить несколько ответов в качестве правильного ответа!

Answer 1

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

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

Answer 2

JUnit позволяет вам проводить тесты, как и в вашей сети, но также:

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

Answer 3

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

Answer 4

Это не страшно, но не рекомендуется по двум причинам:

1. Это может позволить пользователям делать то, что вы не хотите, чтобы они делали, или, по крайней мере, дать им идею, что они могут делать то, что вы предпочли бы не делать; и
2. Прочные методы main () часто являются плохой заменой для модульных тестов.

Это (2) вы должны действительно сконцентрироваться.

Answer 5

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

Это четко отделяет тесты от вашего кода.

Answer 6

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

Во-вторых, и это не было упомянуто до сих пор, если у каждого класса есть метод main, довольно трудно найти «реальную» точку входа в приложение. Если я увижу класс с методом main, я ожидаю, что это позволит мне «использовать» класс по назначению. Я не ожидаю, что это начнет тестовый случай (возможно, с серьезными побочными эффектами).

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

Answer 7

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

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