Создание тестового набора в большой существующей кодовой базе Java

Я работаю над веб-приложением с существующей базой кода, которая, вероятно, существует уже 10 лет, есть ~ 1000 файлов классов и ~ 100 000 строк кода. Хорошей новостью является то, что код организован хорошо, бизнес-логика отделена от домена контроллера, и существует высокий уровень повторного использования. Плохая новость - это только начало набора тестов (JUnit); там может быть 12 десятков тестов.

Код организован довольно типично для корпоративного Java-проекта. Существует пакет контроллеров stuts-esque, модель состоит почти из объектов данных, существует такой спящий режим, как слой базы данных, который в значительной степени инкапсулирован в объекты доступа к данным, и несколько пакетов услуг, которые являются простыми, автономными и логичными. Конечной целью создания этого набора тестов является переход к процессу непрерывной интеграции.

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

Любые предложения приветствуются. спасибо!

Ответ 1

Начнем с чтения Эффективно работаем с устаревшим кодом (короткая версия здесь). Затем я напишу пару сквозных тестов на дым, чтобы охватить наиболее распространенные случаи использования. Вот несколько идей о том, как подойти к нему: http://simpleprogrammer.com/getting-up-to-bat-series/

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

Ответ 2

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

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

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

Удачи!

Ответ 3

Если проект еще не изменен, я бы сделал это. Также не забудьте использовать насмешливую структуру, такую как mockito. Hudson - хороший инструмент CI, который прекрасно сочетается с maven.

Ответ 4

Похоже, вы собираетесь писать как единичные, так и функциональные тесты, поэтому JUnit, возможно, не подходит для этого. Вы считали TestNG? Поскольку у вас только очень мало тестов прямо сейчас, у вас есть возможность выбрать то, что лучше всего подходит для работы.