Как Вы ускоряете модульные тесты Java?

Question

Как Вы ускоряете модульные тесты Java?

Приведенное ниже решение решило мою проблему, а также сохранило значения по умолчанию

$('body').on('hidden.bs.modal', '.modal', function () { 
  $(this).find('input[type="text"],input[type="email"],textarea,select').each(function() { 
    if (this.defaultValue != '' || this.value != this.defaultValue) {
         this.value = this.defaultValue; 
    } else { this.value = ''; }
  }); 
});

32

unit-testing java performance ant

задан IAdapter 18 June 2009 в 07:19

16 ответов

Другие вопросы по тегам:

unit-testing java performance ant

Похожие вопросы:

score 29 · Answer 1

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

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

Время ваших тестов . Обычно 90% из них выполняются практически мгновенно, а последние 10% занимают почти все время. Найдите эти 10% и посмотрите, что они делают.

Запустите код через профилировщик и отметьте, на что тратится время. Гадать - пустая трата времени. То, что вы думаете , что делает тестовый бегун, бессмысленно. Вместо того, чтобы гадать, узнайте , что он делает. Тогда вы узнаете, как его ускорить.

score 2 · Answer 2

Ну, я не знаю, что делает ваш Unit-тест, но вы должны спросить себя , почему он занимает 20 минут. По моему опыту, часто бывает много тестов, которые выполняются за несколько миллисекунд, и несколько тестов, которые составляют остальное необходимое время. Чаще всего это тесты с участием IO / network / DB-Stuff. Например, если вы тратите много времени на ожидание из-за сетевых задержек, вы можете рассмотреть возможность параллельного запуска тестов.

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

score 1 · Answer 3

Перенести полный набор тестов в систему движка непрерывной интеграции, чтобы разработчикам не приходилось запускать их все каждый раз. У таких систем НАМНОГО больше терпения, чем у разработчиков.

score 1 · Answer 4

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

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

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

score 3 · Answer 5

Очевидно, что в вашем тесте есть что-то, что занимает много времени.

Иногда вы не можете обойтись без медленного теста. Например, проверка того, что Spring может читать все файлы конфигурации, проверка работоспособности отображения гибернации и тому подобное. Эти тесты хороши тем, что их нужно запускать только в одном тесте, а затем вы можете смоделировать все это, но вы также можете решить запустить их как часть интеграционного теста и позволить серверу сборки позаботиться об этом.

Остальные тесты медленны либо потому, что они выполняют ввод-вывод, либо потому, что они чрезмерно ограничены процессором.

Операции ввода-вывода могут быть разными. Вызовы веб-служб и баз данных можно абстрагировать и имитировать, а несколько реальных вызовов, которые вам нужно сделать, можно при необходимости перенести на этап интеграции. Ведение журнала тоже может сильно замедлить работу - особенно с 3000 тестовых примеров. Я' Я скажу, что просто полностью отключите ведение журнала и полагайтесь на свой мозг и свой отладчик, когда тест не пройден.

Могут быть случаи, когда сам IO является тестируемым устройством. Например, если вы тестируете часть сервера базы данных, которая записывает данные таблицы на диск. В этом случае постарайтесь сохранить в памяти как можно больше операций ввода-вывода. В Java многие абстракции ввода-вывода имеют реализации в памяти.

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

И, наконец, профилировщик твой друг.

score 4 · Answer 6

Используете ли вы fork = "yes" в своем вызове junit ? Если это так, убедитесь, что вы установили forkMode = "once" , иначе задача junit запустит новую виртуальную машину для каждого класса TestCase. С 3000 модульных тестов это будет иметь огромное значение.

http://ant.apache.org/manual/Tasks/junit.html

score 5 · Answer 7

Для начала:
a) Получите статистику о времени выполнения ваших тестов Junit. Возможно, вы уже указываете эту информацию в своих отчетах об испытаниях.
б) Возьмите 10 лучших тестовых классов (по времени) и постарайтесь сократить время. Это нужно делать на постоянной основе.
c) Попробуйте сократить время выполнения за счет рефакторинга или даже изменения подхода к тестированию.
Один из таких случаев, с которыми я столкнулся, находится в одном классе Test для тестовых примеров CRUD. Тестовый пример обновления сначала создавал функциональность, а затем обновлял. Но мы уже тестировали создание в отдельном тестовом примере. Поэтому в этих случаях вы можете связать свои тестовые примеры, например

@Test()
    public void testCreate() throws Exception
    {}
    @Test(dependsOnMethods = "testCreate")
    public void testAmend() throws Exception
    {}
    @Test(dependsOnMethods = "testAmend")
    public void testDelete() throws Exception
    {}

Таким образом, вы экономите на повторном тестировании.

г) Был еще один случай, когда я смог значительно сократить время. У нас была система (inherietd), в которой каждый тестовый пример вызывал SetUp (Strating Spring Server и т. Д.) И после запуска отключал системные ресурсы. Это занимало очень много времени, поэтому я реорганизовал ее, чтобы запустить ресурсы coomon перед тестовым костюмом и после того, как весь набор готово, затем закройте их.

e) В зависимости от вашего проекта могут возникнуть другие узкие места, которые вам, возможно, придется устранить.

Как управлять временем сборки в TDD

score 4 · Answer 8

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

Если так, один из подходов - это многопоточность выполнения вашего теста. Test-NG очень хорошо это поддерживает. Преобразование тестов из junit в test-ng не так сложно, и их нужно выполнить только один раз.

Тесты, которые необходимо запускать последовательно, можно легко пометить:

@Test(sequential = true)
public class ATest {
  ...

На многоядерной машине вы увидите огромные улучшения во времени выполнения. Даже на одном ядре вы увидите хорошее улучшение, так как некоторые потоки ждут операций io.

Подробнее о том, как это настроить, см. Здесь:

http://beust.com/weblog/archives/000407 .html

Надеюсь, это поможет.

....

Еще несколько предложений - Не могу поверить, что вы не используете непрерывную интеграцию. Поверьте, 30 разработчиков не станут перегружать ваш CI-сервер. Даже если вы не можете получить бай-ин для CI, установите hudson на свой компьютер - это займет 10 минут, и преимущества огромны. Спросите своего менеджера, что хуже, если каждый разработчик ждет завершения модульных тестов или сервер делает это за вас. Иметь дурацкую шляпу для человека, который сломал сборку, обычно достаточно, чтобы убедить разработчиков запустить свои модульные тесты.

Если качество проверок действительно вызывает серьезную озабоченность (не забывайте, что проверка всегда может быть откат) рассмотреть Teamcity - он запускает тесты и не фиксирует код, если тесты терпят неудачу.

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

Но помните, что умные инструменты, такие как test-ng, teamcity и clover, дадут вам только пока - хорошие тесты не будут писать сами себя!

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

Оптимизация тестов - макеты, стандартная настройка и т. д.
Запуск тестов параллельно
Получите что-нибудь еще для запуска тестов - сделайте это автономной задачей, используя hudson или аналогичный
Запускать только тесты, которые необходимо запустить - рассортируйте их по пакетам или используйте клевер и бамбук.

score 10 · Answer 9

Вы можете разделить свои модульные тесты на наборы. Ваше приложение модульное? Как часто действительно нужно запускать все тесты? Было бы приемлемо, если бы ваши разработчики запускали только модульные тесты, относящиеся к их собственному модулю, и у вас был массив тестов, запускаемых каждую ночь и / или на CI?

Существуют ли какие-либо конкретные модульные тесты, которые очень сложны (я знаю , Здесь я скатываюсь к функциональному и интеграционному тестированию, но строка иногда нечеткая), но можно ли запустить любой из них на уровне работоспособности во время разработки, а затем полностью запустить на CI?

Править : Ради удовольствия, я кратко опишу процедуры тестирования в одном из моих предыдущих проектов

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

На уровне разработчика мы использовали простой двухминутный набор тестов под названием CheckIn, который подтвердил, что код достаточно исправен, чтобы присоединиться к магистрали. .
Вдобавок к этому мы постоянно запускали тесты работоспособности на машине CI. Это были упрощенные версии более сложных интеграционных и функциональных тестов, всех модульных тестов и всех регрессионных тестов.
Сложные наборы тестов (по количеству часов) запускались днем и ночью удаленно, а результаты собирались на следующее утро.