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

Question

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

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

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

Два вопроса:

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

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

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

Answer 1

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

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

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% случаев. Скорее всего, этот метод можно разделить на отдельные более легко проверяемые методы.

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