Как вы ускоряете тесты Java?

Question

В настоящее время наш проект имеет более 3000 модульных тестов, и «ant testAll» занимает более 20 минут. кроме улучшения аппаратного обеспечения, есть ли способы ускорить процесс?

Answer 1

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

В инкрементном режиме короткие тесты выполняются примерно за 7 минут, тогда как при полной сборке все тесты выполняются дольше менее чем за 40 минут.

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

Примечание. Один сервер непрерывной интеграции может иметь любое количество агентов, и если вы не можете позволить себе более одного сервера, вы можете использовать ПК в качестве агентов сборок. (Вы должны иметь как минимум 30 из них)

Answer 2

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

1. Не делайте предположений о том, в чем проблема
2. Анализ выполнения теста с помощью профилировщика для определения горячих точек
3. Анализ горячих точек по одному, повторное тестирование после каждого изменения кода.

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

Еще одна область, где вы можете в конечном итоге обнаружить проблемы с производительностью, - это настраиваемые «базовые» классы тестовых примеров. Это, как правило, вещи, которые добавляют много удобства, но может быть сложно вспомнить, что ваши поведения, добавляющие удобство, потенциально амортизируются в течение 10 тыс. Тестов в большом проекте, независимо от того, требуется ли каждому тесту удобное поведение или нет. 1015 *

Answer 3

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

Answer 4

Я согласен с Паблоимом. Распараллелить ваши тесты. Мы используем clearcase и передаем все с серверов просмотра, что сильно замедляет работу. Когда мы распараллеливались на дуэлькоре, мы получили в 6-8 раз более короткий тестовый прогон.

Мы используем инфраструктуру CPPUnit, и мы только что добавили скрипты Python для запуска различных наборов тестов в разных потоках.

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

Answer 5

Доступ к БД и сетевая задержка могут быть областью для изучения. Если вы выполняете большой доступ к базе данных в своих интеграционных тестах, вы можете захотеть использовать базу данных в памяти, такую ​​как HSQL, H2 или Derby, вместо «реальной» базы данных, такой как Oracle. Если вы используете Hibernate, вам также придется изменить настройки в ваших конфигурациях Hibernate, чтобы использовать диалект, специфичный для этой БД (например, HSQLDialect вместо OracleDialect). Когда-то был в проекте, где каждая полная сборка заканчивалась тем, что ему приходилось отбрасывать и воссоздавать всю схему Oracle и выполнять многочисленные тесты БД по сети, а иногда это занимало до 20 минут, а затем вы обнаруживали, что кто-то зарегистрировался и что-то сломалось снова. (

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

БД в той же JVM и БД в сети - может иметь значение.

Answer 6

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

Сложная часть - заставить это работать. В настоящее время я работаю в инкрементном тестировании для JUnit 4, который является частью инструмента "JMockit Coverage" в JMockit инструментарии тестирования разработчика Это все еще незрелое, но я верю, что это будет хорошо работать.