
<html><head><meta http-equiv="Content-Type" content="text/html charset=koi8-r"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><div>On 22.01.2014, at 15:21, Илья Винокуров <<a href="mailto:ilvin@mail.ru">ilvin@mail.ru</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

<div><br>У вас в объекте есть несколько методов, которые по идеологии юнит тестирования нужно/можно протестировать отдельно.<br>Например: <br><strong>new</strong> - хорошо бы протестировать, что этот метод правильно производит начальную инициализацию переменных в зависимости от переданныех параметров<br></div></blockquote><div><br></div><div>на такой бред я не буду тратить время.</div><br><blockquote type="cite"><div><strong>set_favicon</strong> - проверить, что устанавливается переменная $self->{ico}<br></div></blockquote><div><br></div><div>а если я решу переписать механизм? проверять нужно, что после set_favicon запрос на /favicon возвращает то, что нужно (т.е. опять-же - функционал)</div><br><blockquote type="cite"><div><strong>listen</strong> -</div></blockquote><blockquote type="cite"><div>проверить, что сервер действительно начинает слушать нужный сокет.</div></blockquote>ок, допустим.<br><blockquote type="cite"><div>Проверить, что правильно парсятся разные синтаксисы хостов, сервисов. </div></blockquote>это функционал другого модуля<br><blockquote type="cite"><div>Проверить поведение сервера в ошибочных ситуациях.</div></blockquote>возможно<br><blockquote type="cite"><div> Проверить, что сокеты переводятся в неблокирующий режим.</div></blockquote><div><br></div><div>зачем?</div><div>проверять вызов fh_nonblocking $fh, 1;?</div><div>может быть начнём еще проверять, что вызов print "hello world" отрабатывает как нужно?</div></div><div><font color="#333333" face="Consolas, Liberation Mono, Courier, monospace"><span style="line-height: 18px; white-space: pre;"><br></span></font><blockquote type="cite"><div> Проверить поведение метода для разных OS. </div></blockquote><div><br></div></div><div><blockquote type="cite"><div>Проверить, что метод действительно вызывает другой метод prepare.</div></blockquote><div><br></div><div>там код линейный. как он может его не вызывать?</div><br><blockquote type="cite"><div><strong>accept</strong> - Проверить, что метод вызывается при коннекте клиента.</div></blockquote><blockquote type="cite"><div>Проверить поведение метода, когда $fn == undef. </div></blockquote><div>это неконсистентное состояние объекта</div><br><blockquote type="cite"><div>Проверить, что сокет переводится в неблокирующий режим.</div></blockquote><blockquote type="cite"><div>А что происходит, если сокет не смог перейти в неблокирующий режим?</div></blockquote>это как?<br><blockquote type="cite"><div> Проверить, что метод вызывает incoming с правильными аргументами, в зависимости от флага $self->{want_peer}<br></div></blockquote>чтобы это проверить эти 5 строк, в которых негде ошибиться, нужно написать строк 50 теста. зачем?<br><blockquote type="cite"><div><br>И так далее по каждому методу.<br></div></blockquote><div><br></div><div>Какие-то вещи, несомненно, имеют смысл, но на большинство мне жаль тратить время.</div><div>какие-то из описываемых кейсов предполагают влезание внутрь объекта.</div><div><br></div><div>если вы из автомобиля выкрутить 1 свечу или открутите колесо, вы предполагаете, что машина корректно обработает эту ситуацию?</div><div><br></div><blockquote type="cite"><div><br>Ведь задача юнит тестов - фиксирование интерфейсов взаимодействия разных частей программы.</div></blockquote><div><br></div><div>вот именно, программы.</div><div>модуль обязан соблюдать только внешний интерфейс.</div><div>внутренности я могу переписывать как угодно.</div><div>и тестировать внутреннее взаимодействие не вижу смысла.</div><div><br></div><blockquote type="cite"><div>И нужно это для того, чтобы программист сразу видел места, поведение которых изменилось после последнего коммита.<br><br>> Модуль здесь - AE::HTTP::Server.<br>> тесты проверяют, что этот модуль функционирует корректно.<br><br>Ваши тесты проверяют, что модуль в целом функционирует. Относительно всей программы, в которой используется модуль тесты можно назвать юнит-тестами, а вот относительно вашего модуля я назвал ваши тесты функциональными, т.к. вы поставляете только этот модуль...<br><br>Или я о каком-то другом виде тестирования говорю?<br><br>Кстати, интересно будет услышать в докладе темы:<br>1) Виды тестирования (в качестве введения в тему)<br>2) Зачем нужны тесты<br>3) Нужно ли тестировать поведение модуля в ситуациях возникновения ошибок<br>4) До какой степени нужно покрывать тестами код программы.<br>5) Как юнит-тесты помогают в командной разработке<br>6) Как юнит-тесты помогают при рефакторинге кода.<br>7) Как сильно TDD замедляет разработку<br><br></div></blockquote></div><br><div>В общем про тесты и документацию это не ко мне )</div><div>по документации мой ответ - код лучшая документация.</div><div>про тесты - уже написал выше.</div><div><br></div><div>могу, разве что, придумать по просьбе сообщества механизмы для тестирования AE</div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>