Во-первых, если у вас уже есть большая система, в которой нет юнит-тестов, и вы планируете добавить их, то позвольте мне дать несколько общих советов.
От обслуживания системы и работы с ней вы, вероятно, уже будете знать области системы, которые имеют тенденцию быть ошибочными, которые имеют тенденцию часто меняться и которые обычно не меняются. Если вы этого не сделаете, вы всегда можете просмотреть журналы контроля версий (вы используете контроль версий, верно?), Чтобы выяснить, где сосредоточено большинство исправлений и изменений. Сосредоточьте свои усилия на тестировании на этих классах и методах. Существует общее правило, называемое правилом 80/20 , которое применимо ко всему спектру вещей, и это одно из них.
В нем говорится, что примерно в среднем вы должны быть в состоянии покрыть 80 процентов оскорбительных дел, выполнив всего 20% работы. То есть, написав тесты только для 20% кода, вы, вероятно, сможете поймать 80% ошибок и регрессий. Это связано с тем, что большая часть хрупкого кода, часто изменяемого кода и кода с наихудшим нарушением составляет всего 20% кодовой базы. На самом деле, это может быть даже меньше.
Вы должны использовать junit, чтобы сделать это, и вы должны использовать что-то вроде JMock или какую-либо другую библиотеку для проверки, чтобы гарантировать, что вы тестируете изолированно Для системного тестирования / тестирования интеграции, то есть тестирования вещей во время их совместной работы, я могу порекомендовать FitNesse . У меня был хороший опыт с этим в прошлом. Это позволяет вам написать тест в веб-браузере, используя простые макеты в виде таблиц, где вы можете легко определить свои входные и ожидаемые результаты. Все, что вам нужно сделать, это написать небольшой вспомогательный класс, называемый Fixture, который обрабатывает создание компонентов.