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

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

2 голосов
/ 26 января 2012

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

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

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

Два вопроса:

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

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

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

1 Ответ

3 голосов
/ 26 января 2012

Вот мой вклад по этому вопросу:

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

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

...