Профилирование тестов JUnit с помощью PowerMock?

У нас есть пара очень-очень медленных тестов JUnit, которые активно используют насмешки, в том числе насмешки над статическими функциями. Одиночные тесты занимают 20-30 секунд, весь «тест mvn» занимает 25 минут.

Я хочу проанализировать, где тратится время, но у меня мало опыта в профилировании.

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

Два вопроса:

1) Как быстро получить номера, на какие методы тратится время? Мне не нужен сложный инструмент для опытных пользователей, просто что-то базовое, чтобы получить цифры. (доказательство того, что наши насмешки — это зло)

2) Есть ли у вас идеи, какие недостатки дизайна могут привести к таким плохим таймингам? Мы тестируем компоненты поддержки JSF, которые должны вызывать фиктивные службы. Возможно, во вспомогательных компонентах может быть некоторая проверка ввода или бизнес-логика без рефакторинга, но это нельзя изменить (пожалуйста, не комментируйте это ;-))

объявление 2) Например, в одном тесте есть около 30 (!) классов, которые нужно подготовить к тесту с помощью @PrepareForTest. Это не может быть хорошо, но я не могу объяснить, почему.


junit profiling jsf powermock
person Bastl    schedule 26.01.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Вот мой вклад в это:

  1. Попробуйте использовать что-то простое, например Секундомер Apache Commons класс. Я считаю, что это простой способ обнаружить узкие места в коде, и обычно, когда вы находите первое узкое место, то и остальные легче обнаружить. Я почти никогда не трачу время на настройку слишком сложного инструмента профилирования.

  2. Я думаю, что странно, что у вас есть такие недостатки производительности в полностью смоделированных модульных тестах. Если бы я предположил, я бы сказал, что вам не хватает одного или двух фиктивных компонентов, а база данных или внешние веб-сервисы на самом деле вызываются без вашего ведома. Конечно, я могу ошибаться, потому что я не использую PowerMock и никогда не имитирую какие-либо статические методы. Это ваш самый большой недостаток дизайна прямо сейчас и самое большое препятствие для обеспечения хорошего покрытия тестами вашего кода. Так что делать? У вас есть 2 варианта: вы можете преобразовать статические методы в методы класса, которые легче смоделировать. Другой вариант заключается в том, что вы оборачиваете статические методы в оболочку объекта класса, а затем вместо этого издеваетесь над оболочкой. Обычно я делаю это, если статические методы взяты из сторонней библиотеки, где у меня нет исходного кода.

  3. one test has about 30 (!) classes to be prepared for test with @PrepareForTest. This cannot be good, but I cannot explain why. Это действительно похоже на то, что у вас также могут быть методы, которые делают слишком много! Это слишком много зависимостей для одного метода примерно в 99% случаев. Скорее всего, этот метод можно разделить на отдельные, более легко тестируемые методы.

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

person maple_shaft    schedule 26.01.2012