Как убедить членов команды в существовании «Мандельбуга»

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

Недавно я обнаружил, что mandelbug иногда вызывает сбой приложения. Я мог воспроизвести его один раз и получить трассировку стека, поэтому я открыл отчет об ошибке. Саму ошибку легко исправить (необработанное веб-исключение в одном из фоновых потоков, которое заставляет CLR прекратить работу программы).

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

Любой совет?

Если возможно, возможно, потратьте некоторое время, чтобы проверить, можно ли воспроизвести этот дефект , поместив некоторое время сна или блокировки в код приложения. Но не тратьте слишком много времени. Поскольку эта проблема связана с многопоточностью (а также, как вы заметили), ее возникновение будет редким.

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

Также попытайтесь понять менталитет разработчика. Вы сказали «неисследованное веб-исключение». Разработчик на данном этапе может быть не совсем уверен, каковы будут другие последствия этого . Так что он / она, возможно, не хочет трогать код.

Итак, из ваших более или менее разъясняющих комментариев я понял это так:

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

Тогда почему бы вам не добавить несколько пропущенных строк кода в библиотеку самостоятельно, попросить команду протестировать библиотеку с этими изменениями? Убедитесь, что это изменение с низким уровнем риска, понятное для разработчика, ответственного за lib. Худшее, что может случиться, это то, что кто-то должен отменить это изменение в вашей VCS, если ваше исправление вызывает какое-то новое неожиданное поведение.

Большинству людей легче убедить, когда работа уже сделана. Кроме того, они лучше реагируют на «вот улучшенное решение», а не «этот код неправильный, исправьте его как-нибудь».

РЕДАКТИРОВАТЬ: когда разработчик по-прежнему отказывается добавить это изменение, лучшим вариантом будет попытка заставить проблемный код работать в изолированном тестовом жгуте, где вы симулируете сетевую ошибку. Эффективная работа с унаследованным кодом описывает множество методов решения таких проблем. Например, вы можете создать тестовую версию библиотеки, включающую только проблемные модули и функции, и создать вокруг нее «фиктивную среду», в которой вы можете смоделировать «сетевое исключение» в контролируемых условиях. На первый взгляд это может показаться слишком большим усилием, но если у вас есть такая среда, вы можете добавить к ней множество дополнительных тестов (и я думаю, это будет иметь смысл, поскольку, когда автор библиотеки отказывается добавлять отсутствующие обработка исключений в одном месте,

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

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

Адвокат дьявола предлагает другой путь.

Другой разработчик категорически заявил, что там нет ошибок.

Можете ли вы придумать способ подчеркнуть ад из его якобы несуществующей ошибки и заставить ее чаще падать?

Трассировка стека является очевидным доказательством того, что ошибка существует или, по крайней мере, существовала в определенной сборке. То, что у вас нет, является доказательством того, что ошибка была исправлена. Они глупы, чтобы игнорировать это. У меня были «невозможно воспроизвести» ошибки после сотен тысяч автоматических попыток на нескольких системах, которые запускались каждый раз в системе клиента.

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

Например, несколько месяцев назад я исправил ошибку, которая возникала только тогда, когда пользователь печатал быстрее 96 слов в минуту. До того, как я исправил это, все, что я знал, было то, что ошибка случалась "иногда". Мне никогда бы не пришло в голову написать модульный тест для быстрой печати. Однако, после того, как я узнал причину, сделать тестирование было тривиально.

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