Автогенерация юнит-тестов для унаследованного Java-кода

Question

Какой лучший, желательно бесплатный / открытый инструмент для автоматической генерации Java-тестов? Я знаю, что модульные тесты не могут служить той же цели, что и обычные модульные тесты TDD, которые документируют и определяют структуру системы. Однако автоматически созданные модульные тесты могут быть полезны, если у вас огромная устаревшая кодовая база и вы хотите знать, будут ли внесенные вами изменения иметь нежелательные, неясные побочные эффекты.

Answer 1

Не бесплатно. Не с открытым исходным кодом. Но я обнаружил, что AgitarOne Agitator (http://www.agitar.com/solutions/products/agitarone.html) ДЕЙСТВИТЕЛЬНО хорош для автоматической генерации юнит-тестов и поиска нежелательных неясных побочных эффектов

Answer 2

Плагин Coview для Eclipse (http://www.codign.com/products.html) выглядит просто работой. Я заинтересован в создании тестов, которые охватывают все пути в коде, и это, похоже, делает это. Он также генерирует макеты, которые должны сэкономить мне массу время.

Answer 3

Это интересно, но такие сгенерированные модульные тесты действительно могут быть полезны. Если вы работаете с унаследованным приложением, часто будет сложно написать правильный, современный модуль тесты.

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

Теперь о , генерирующем себя . Я не знаю ни о каком волшебном инструменте, но вы можете поискать функциональность JUnit о включении некоторых тестов в javadocs для методов. Это позволит вам написать несколько простых тестов. И да, это действительно какая-то ценность.

Во-вторых, вы можете просто написать «большие» тесты вручную. Конечно, это не будут модульные тесты per se (без изоляции, потенциальных побочных эффектов и т. Д.), Но это может быть хорошим первым шагом. Особенно, если у вас мало времени и унаследованное приложение.

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

Answer 4

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

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

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

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