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

например ты написал тесты к коду:

sub middle {
  ( $x + $y) / 2
}

но потом в нём баг - ($x + $y) подвержен целочисленном переполнению
(или превращается в float в perl), хотя и $x и $y могли бы влезть в
integer

и ты об этом не подумал когда писал код и смотрел на него, так что и
юнит тест не написал.

Ну и как пользоваться дебагером - если есть багрепорт, он начинается с
того, как баг можно воспроизвести. Вот если это веб-приложение, то и
воспроизводишь его в веб-приложении и уже в этот
момент можно пользоваться дебагерром, а только потом уже станет
понятно где конкретно баг какой test-case написать, чтобы баг
воспроизводился.

27 марта 2016 г., 21:26 пользователь Ilya Chesnokov
<[email protected]> написал:
> А как использовать дебаггер без юнит-тестов? :-)
>
> 27 марта 2016 г., 14:35 пользователь Victor Efimov <[email protected]> написал:
>> Это перпендикулярные вещи. Как пишущий юнит тесты, скажу, что дебагер
>> иногда очень даже нужен. Хотя те кто не пишут, им он, наверное, нужен
>> постоянно
>>
>> 27 марта 2016 г., 14:29 пользователь Roman V. Nikolaev
>> <[email protected]> написал:
>>> Самый лучшей дебаггер это юнит тесты. Помимо удобного вывода и контроля,
>>> Вы получаете намного, намного больше.
>>>
>>> --
>>> Roman V. Nikolaev
>>> --
>>> Moscow.pm mailing list
>>> [email protected] | http://moscow.pm.org
>> --
>> Moscow.pm mailing list
>> [email protected] | http://moscow.pm.org
>
>
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> [email protected] | http://moscow.pm.org
-- 
Moscow.pm mailing list
[email protected] | http://moscow.pm.org

Ответить