Как лучше всего протестировать код Java?

Мокинг - хороший способ имитировать системные тесты в модульном тестировании; заменяя (имитируя) ресурсы, от которых зависит другой компонент, вы можете выполнять модульное тестирование в «системной» среде без необходимости создавать для этого всю систему.

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

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

При работе с API (для других пакетов или URL-адресов или даже для файла / сети / базы данных) вы должны имитировать их. Хороший модульный тест должен выполняться за несколько миллисекунд, а не за секунды. Издевательство - единственный способ сделать это. Это означает, что с ошибками между пакетами можно справиться намного проще, чем с логическими ошибками на функциональном уровне. Для Java easymock - очень хороший фреймворк для создания макетов.

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

From поддерживая систему и работая с ней, вы, вероятно, уже знаете те области системы, которые имеют тенденцию к наибольшим ошибкам, которые имеют тенденцию часто меняться и которые, как правило, не меняются очень сильно. Если вы этого не сделаете, вы всегда можете просмотреть журналы системы управления версиями (вы используете систему управления версиями, верно?), Чтобы узнать, где сосредоточено большинство исправлений ошибок и изменений. Сосредоточьте свои усилия по тестированию на этих классах и методах. Существует общее правило, называемое правило 80/20 , которое применимо к целому ряду вещей, и это одна из них.

В нем говорится, что примерно в среднем, вы сможете покрыть 80 процентов случаев нарушения, выполнив лишь 20% работы. То есть, написав тесты только для 20% кода, вы, вероятно, сможете отловить 80% ошибок и регрессов. Это потому, что большая часть хрупкого кода, часто изменяемого кода и наиболее опасного кода составляет всего 20% кодовой базы. Фактически, это может быть даже меньше.

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

Вы можете взглянуть на этот список: Инструменты для регрессионного тестирования / автоматизации тестирования Java-приложения, ориентированного на базы данных? - список интересных инструментов.

Как вы Похоже, что вы уже широко используете Junit, это означает, что вы уже "заражены тестом", и это хороший момент ...

По моему личному опыту, самое сложное в управлении - это данные. Я имею в виду, очень внимательно контролировать данные, которые запускаются при тестировании.

Приведенные выше списки инструментов полезны. Исходя из личного опыта, я считаю полезными следующие инструменты:

Mocking - Mockito - отличная реализация, в которой есть хитрые приемы, гарантирующие, что вам нужно только имитировать методы, которые вам действительно нужны.

Тестирование базы данных - DBunit незаменим для настройки тестовых данных и проверки взаимодействия с базой данных.

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

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

Хотя этот уровень тестирования должен быть вторичным по отношению к хорошему модульному тестированию.

Удачи!