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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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