Тестирование с помощью ASM Bytecode - PullRequest
2 голосов
/ 02 ноября 2011

Допустим, я инструментирую класс, в который я хочу добавить пару инструкций для некоторых частей метода. Например, давайте рассмотрим случай, когда я хочу разработать посетителя V для переименования инструкций вызова метода, существующих в методе C.m(), с C.n() до C.n_detour().

Какой самый простой способ проверить, что после запуска V над C можно действительно получить желаемые результаты? Я говорю о тестировании стиля xUnit здесь.

Сначала я подумал, что смогу запустить TraceMethodVisitor поверх C и сравнить его со своей собственной строкой, но оказалось, что существует много инструкций по "оформлению" (таких как нумерация строк и т. Д.) которые в основном не имеют отношения к моим тестам (см. Форматирование вывода TraceClassVisitor ).

Теоретически я знаю, что мог бы сделать некоторого посетителя, который запустит и проверит как существование C.n_detour(), так и несуществование C.n(), но я бы предпочел использовать что-то более в соответствии с вышеприведенным подходом (сравнение инструкций с инструкцией).

Я посмотрел на Tree API ASM, но он выглядит не намного лучше, так как там тоже есть эти decoration инструкции.

Есть ли у кого-нибудь опыт в прошлом тестировании кода с использованием ASM?

1 Ответ

1 голос
/ 02 ноября 2011

Сделать C.n_detour() защищенным, расширить C в тестовом примере и подсчитать количество вызовов.

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

Может потребоваться новый загрузчик классов, чтобы поместить инструментальную версию C в путь к классам.

Если вы используете Maven, я предлагаю инструмент в одном модуле и поместить тесты во второй модуль.

...