Комментарии 6
Ну некрасиво yooteam поступает. Написала вопросы и ссылки на ролики в ютуб вставила в качестве ответа. И в роликах даже таймкодов нету. Так ладно бы сами пользователи в комментариях таймкоды бы сделали, так нет, комментарии отключили.
Вопросы по инъекции тестовых поведений:
1) Придумали же контейнеры для бинов, которые можно подменять mock объектами с тестовыми поведением, а тут зачем-то прям методы заменяем и называем это Side Effect Injection, не кажется что велосипед изобретаем?
2) Если запускать в режиме Debug как быстро стартуют те инструменты, что вы сравнивали?
AlexeyOs, привет!
1) Иногда кажется)) Но от идеи не отказываемся, потому что:
- Работа с бинами — это специфика IoC, которого может не быть в приложении вовсе (и это не всегда значит, что приложение плохое, а разработчики — бракоделы)
- Даже если всё-таки закладываться на наличие IoC-контейнера, то какого? Только лишь Spring? А может, Guice? А вдруг там CDI? Поддерживать каждый — такое себе решение. Гораздо целесообразнее не наступать себе на горло и не зависеть от этой переменной составляющей.
- И потом, а где тогда хранить mock-бины? В
src/test/javaне пойдёт, потому что модифицированное поведение нам нужно не в тестах, а в обычном режиме работы приложения. Класть к основным исходникам, конечно, можно, но это возвращает нас к обычному подходу "If'ы+настройки", а значит, эти тестовые поделки снова уедут на production и защита от их случайного срабатывания снова ляжет на совесть людей, а не на формальный механизм выкашивания лишнего. Впрочем, буду честен, пару раз, в особонакуренныхнетривиальных случаях мы сами так делали, но только подключение тестового бина обеспечивали не настройкой, а дроплетом, т.е. в отсутствие модицификации тестовый бин вообще никак не попадал в IoC-контейнер и даже не загружался как класс в JVM. Это пример комбинации подходов, о которой я говорил в конце доклада. Другой пример см. на этих слайдах другой версии доклада.
2) Для AspectJ и Byteman специальных тестов по этой части не делал, разве что чисто визуально кажется, что AspectJ стартует чуть медленнее. Что касается jMint, то у нас в тестовом окружении большинство приложений по умолчанию стартуют одновременно и с отладчиком (в режиме suspend=n, разумеется), и с Java-агентом jMint, но на времени старта это не сказывается. С точки зрения подкапотной механики, отладчик не привносит здесь ничего нового, поэтому и не вызывает задержек. Единственная особенность — в порядке подключения агентов (ведь отладчик — тоже агент, только "нативный"). Если в команде запуска JVM указать агентов не в том порядке, то отладчик не сможет ходить по исполняемому коду jMint (впрочем, вряд ли этого кого-то волнует).
Работа с бинами — это специфика IoC
Если надо тестировать поведение одного конкретного бина зачем вообще поднимать контейнер? В чём проблема создавать его в тесте вручную?
И потом, а где тогда хранить mock-бины? В src/test/java не пойдёт, потому что модифицированное поведение нам нужно не в тестах, а в обычном режиме работы приложения.
Именно в src/test/… и хранить, если мы говорим про тесты. А вот для чего нужно модифицированное поведение не в тестах, я слабо себе представляю. Вы прям полностью приложение собираетесь поднимать? Тогда это уже интеграционные тесты, которые лучше вообще в отдельный артефакт выделить.
Если надо тестировать поведение одного конкретного бина зачем вообще поднимать контейнер? В чём проблема создавать его в тесте вручную?
Дело как раз в том, что далеко не всегда задача сводится к тестированию одного бина; нередко возникает потребность модификации сквозных поведений или функционала, не обёрнутого в бины. Больше того, применение Side Effect Injection отнюдь не сводится к одному лишь тестированию. Слово "тестовый" в названии доклада означает, в первую очередь, принадлежность к тестовому (не production) окружению. Например, когда нужно временно поменять что-то в библиотечном коде или на определенном этапе отключить проверки безопасности.
Именно в src/test/… и хранить, если мы говорим про тесты
Если бы речь была только о тестах, то, безусловно, да, так и нужно было бы сделать. Но как я говорил в докладе и повторился чуть выше здесь, это далеко не всегда так.
Вы прям полностью приложение собираетесь поднимать? Тогда это уже интеграционные тесты, которые лучше вообще в отдельный артефакт выделить.
Да, полностью, и да, можно (хоть и не обязательно) выделять в отдельный артефакт, так как SEI — это не разновидность тестов, а альтернативный подход к troubleshooting'у и воспроизведению сложных тестовых кейсов. Его можно использовать как в составе интеграционных тестов, так и самостоятельно.
Как оптимизировать повседневные backend-задачи: три видео с митапа по Java