Comments 21
Может быть полезно для тестирования.
Вот что думает о дебаггерах один из апологетов TDD, Роберт Мартин.
Что вовсе не значит, что дебаггинг при тестировании — это зло. Любому инструменты есть свое применение.
Конечно, апологеты TDD не любят дебаггеры — ведь люди используют их вместо тестов (-:
Но надо мыслить позитивно. Представте себе, что вы используете дебаггер чтоб доказать наличие ошибки в коде другой комманды, которая не пишет тесты, специально чтоб убедить их что тесты нужно писать (-;
О том, что юнит тестами сложно отловить например ошибки, связанные с многопоточностью, вспоминать не будем.
Но надо мыслить позитивно. Представте себе, что вы используете дебаггер чтоб доказать наличие ошибки в коде другой комманды, которая не пишет тесты, специально чтоб убедить их что тесты нужно писать (-;
О том, что юнит тестами сложно отловить например ошибки, связанные с многопоточностью, вспоминать не будем.
О том, что юнит тестами сложно отловить например ошибки, связанные с многопоточностью, вспоминать не будем.
А с использованием дебаггера многие ошибки связанные с многопоточностью так вообще отловить невозможно.
А с использованием дебаггера многие ошибки связанные с многопоточностью так вообще отловить невозможно.
С помощью очень хитрого — в принципе, можно: управляя шагами потоков, проще искусственно привести их к дедушке Локку ;-)…
Дедлоки, это конечно неприятно, но лишь частный случай всех проблем с многопоточностью. Проблема с тестированием многопоточности в том, что ошибки могут возникать с невероятно низкой вероятностью, а вмешательство дебаггера гораздо больше нежели вмешательство тестов (где мы, к примеру можем проверять состояние каждые… допустим 1000 итераций).
При работе с дебаггером мейджика гораздо больше, и, если я не ошибаюсь, код, который мы дебажим не совсем тот код, который мы имеем после JIT-а, поэтому в данной ситуации мы дебажить можем совершенно не то, что нам нужно
При работе с дебаггером мейджика гораздо больше, и, если я не ошибаюсь, код, который мы дебажим не совсем тот код, который мы имеем после JIT-а, поэтому в данной ситуации мы дебажить можем совершенно не то, что нам нужно
А меня учили, что воспроизведение дедлоков средствами дебаггера почти невозможно. О лайвлоках и вспоминать не стану.
Пусть думает дальше, это же его хлеб.
У вашего апологета рассматривается слишком узкий случай использования дебаггера — рытье стектрейсов в поисках ошибок, прыжки по брейкпоинтам и тп, в общем, типичная для дебаггеров работа… А если посмотреть немного пошире, в контексте данного поста? Когда я писал, что эта техника может быть полезна для тестирования я вовсе не имел в виду отлов ошибок, скорее дополнительные возможности для создания условий тестирования, например, имитация непредвиденных критических ситуаций, типа, битых данных или попыток обхода лицензионной защиты (подменяя переменные, код и тп), или наоборот — штатных (ответ сервера, etc..), или считывание состояния приложения, строя какие-то графики зависимостей, исследуя отклонения от нормы и так далее… Я ничего не имею против TDD и Роберта Мартина, я лишь говорю, что такой подход можно взять на вооружение, дополнительно ко всему остальному, не вместо, а вместе!
Думаю, много полезнее был бы развитый анализ происхождения значение переменных и выражений и развитый трейсинг выполнения. В сущности, дебаггер обычно запускают для того, чтобы узнать, откуда берётся то или иное значение.
Приведённый в статье инструментарий в принципе достаточен, чтоб, хоть и по хитрозакрученным методикам, но сделать подобную вещь.
Приведённый в статье инструментарий в принципе достаточен, чтоб, хоть и по хитрозакрученным методикам, но сделать подобную вещь.
Спасибо, очень познавательно.
На самом деле, автоматизированный дебаггинг — это ТЕМА. Жаль (и странно), что я (за других тут говорить не осмелюсь) до сих пор не знаю относительно удобных и простых тулов по этой части…
Немного не ясно, зачем все это :) Разве не быстрее было бы написать log.debug(«variable={}», variable)?
А если я Logger и дебажу? ((-;
Невозможно, если:
— Подглядывается значение переменной в чужом коде (например библиотечной функции)
— Проблемма в самом логгере (-:
— С включённый дебагом проблема репродюсится, а вот с включённым логгированием — нет (вероятность такого крайне мала, но в жизни всё бывает)
Затруднено, если:
— Изменение уровня логгирования забивает логи
— Тестовый сервер под дебагом используют несколько людей, и новый деплой ради одной строчки дебага задержит их работу
— возможно дебаг этой строчки ничего не покажет, и надо будет перейти к следующей и так далее
— Логгирование неуместно в данном конкретном случае — в конце концов нельзя логать значения всех переменных, пусть даже с trace уровнем
Невозможно, если:
— Подглядывается значение переменной в чужом коде (например библиотечной функции)
— Проблемма в самом логгере (-:
— С включённый дебагом проблема репродюсится, а вот с включённым логгированием — нет (вероятность такого крайне мала, но в жизни всё бывает)
Затруднено, если:
— Изменение уровня логгирования забивает логи
— Тестовый сервер под дебагом используют несколько людей, и новый деплой ради одной строчки дебага задержит их работу
— возможно дебаг этой строчки ничего не покажет, и надо будет перейти к следующей и так далее
— Логгирование неуместно в данном конкретном случае — в конце концов нельзя логать значения всех переменных, пусть даже с trace уровнем
Написать-то быстрее, особенно один раз, но 1) после каждого раза пересборка и передеплой, 2) писать придётся не в одном месте, а в 30-50 местах.
Ошибка: не
vm = atconn.attach(prm);
vm = atconn.attach(args);
За
System.out.println(theVariable); return false;
Sign up to leave a comment.
Программный дебаг Java-приложений посредством JDI