Программный дебаг Java-приложений посредством JDI

[Indexator]

Может быть полезно для тестирования.

[butteredcat]

Вот что думает о дебаггерах один из апологетов TDD, Роберт Мартин.

[Ganga]

Что вовсе не значит, что дебаггинг при тестировании — это зло. Любому инструменты есть свое применение.

[Sauron]

Конечно, апологеты TDD не любят дебаггеры — ведь люди используют их вместо тестов (-:

Но надо мыслить позитивно. Представте себе, что вы используете дебаггер чтоб доказать наличие ошибки в коде другой комманды, которая не пишет тесты, специально чтоб убедить их что тесты нужно писать (-;

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

[ashofthedream]

О том, что юнит тестами сложно отловить например ошибки, связанные с многопоточностью, вспоминать не будем.
А с использованием дебаггера многие ошибки связанные с многопоточностью так вообще отловить невозможно.

[Flammar]

С помощью очень хитрого — в принципе, можно: управляя шагами потоков, проще искусственно привести их к дедушке Локку ;-)…

[ashofthedream]

Дедлоки, это конечно неприятно, но лишь частный случай всех проблем с многопоточностью. Проблема с тестированием многопоточности в том, что ошибки могут возникать с невероятно низкой вероятностью, а вмешательство дебаггера гораздо больше нежели вмешательство тестов (где мы, к примеру можем проверять состояние каждые… допустим 1000 итераций).

При работе с дебаггером мейджика гораздо больше, и, если я не ошибаюсь, код, который мы дебажим не совсем тот код, который мы имеем после JIT-а, поэтому в данной ситуации мы дебажить можем совершенно не то, что нам нужно

[butteredcat]

А меня учили, что воспроизведение дедлоков средствами дебаггера почти невозможно. О лайвлоках и вспоминать не стану.

[Flammar]

Я занёс этот ваш коммент в избранное. Интересный challenge. Постараюсь вскоре экспериментально опровергнуть этот тезис которому вас «учили», и написать об этом пост. Если меня не опередит автор этого поста ;-)

[ashofthedream]

Пусть думает дальше, это же его хлеб.

[Indexator]

У вашего апологета рассматривается слишком узкий случай использования дебаггера — рытье стектрейсов в поисках ошибок, прыжки по брейкпоинтам и тп, в общем, типичная для дебаггеров работа… А если посмотреть немного пошире, в контексте данного поста? Когда я писал, что эта техника может быть полезна для тестирования я вовсе не имел в виду отлов ошибок, скорее дополнительные возможности для создания условий тестирования, например, имитация непредвиденных критических ситуаций, типа, битых данных или попыток обхода лицензионной защиты (подменяя переменные, код и тп), или наоборот — штатных (ответ сервера, etc..), или считывание состояния приложения, строя какие-то графики зависимостей, исследуя отклонения от нормы и так далее… Я ничего не имею против TDD и Роберта Мартина, я лишь говорю, что такой подход можно взять на вооружение, дополнительно ко всему остальному, не вместо, а вместе!

[butteredcat]

Вот видите, сколько смысла можно вложить в несколько слов первого комментария. Думаю, что будь у Вас хоть немножечко из той упорности в старании изъяснять свои мысли чисто, этих глупых минусов недоразумения не было бы.

[Flammar]

Думаю, много полезнее был бы развитый анализ происхождения значение переменных и выражений и развитый трейсинг выполнения. В сущности, дебаггер обычно запускают для того, чтобы узнать, откуда берётся то или иное значение.

Приведённый в статье инструментарий в принципе достаточен, чтоб, хоть и по хитрозакрученным методикам, но сделать подобную вещь.

[Lendon]

Спасибо, очень познавательно.

[Flammar]

На самом деле, автоматизированный дебаггинг — это ТЕМА. Жаль (и странно), что я (за других тут говорить не осмелюсь) до сих пор не знаю относительно удобных и простых тулов по этой части…

[relgames]

Немного не ясно, зачем все это :) Разве не быстрее было бы написать log.debug(«variable={}», variable)?

[Sauron]

А если я Logger и дебажу? ((-;

Невозможно, если:
— Подглядывается значение переменной в чужом коде (например библиотечной функции)
— Проблемма в самом логгере (-:
— С включённый дебагом проблема репродюсится, а вот с включённым логгированием — нет (вероятность такого крайне мала, но в жизни всё бывает)

Затруднено, если:
— Изменение уровня логгирования забивает логи
— Тестовый сервер под дебагом используют несколько людей, и новый деплой ради одной строчки дебага задержит их работу
— возможно дебаг этой строчки ничего не покажет, и надо будет перейти к следующей и так далее
— Логгирование неуместно в данном конкретном случае — в конце концов нельзя логать значения всех переменных, пусть даже с trace уровнем

[Flammar]

Написать-то быстрее, особенно один раз, но 1) после каждого раза пересборка и передеплой, 2) писать придётся не в одном месте, а в 30-50 местах.

[Flammar]

Ошибка: не

vm = atconn.attach(prm);

, а

vm = atconn.attach(args);

[Sauron]

Спасибо, исправил.

[Flammar]

За

System.out.println(theVariable); return false;

спасибо, оказывается, не только в FireBug такие приколы работают.