<div dir="ltr"><div><div><div><div><div><div>#3 ответ да<br></div><div> У нас принято так<br> - как минимум два позитивных теста ( коректное поведение потока выполнения)<br></div><div> - как минимум один тест на каждый случай неготивного поведения<br>
</div><div>#4 после #3 как минимум один тест на каждый баг. при таком подходе покрытие будет более 80%, что позволяет "ВАЩЕ_НЕ_ПАРИТСЯ_И_СПАТЬ_СПОКОЙНО"<br></div><div>#5 В контексте командной разработки, самое лучшее это <br>
</div><div> - тесты документация кода<br></div><div> - хороший отпуск, код может легко править любой член команды<br></div><div> - безопастность смены члена команды<br></div><div>#6 Без тестов рефакторить могут только ГУРУ-ЗУБРЫ. Я к тамим не отношусь, так что рискнуть отрефакторить что нить на комерческом проекте 24/7/365 не отважусь, даже при аппруве всего руководства и повышении зп в 2 раза :)<br>
</div><div> А если на пальцах, то <br></div><div> - есть ограниченное количество рефакторингов которые безопастно делать без покрытия тестами. Например рефакторинг "Change Method Signature", очень просто делать в компилируемых ЯП, но не безопастно в динамических. Однако, я не представляю себе (в настоящий момент, не будем говорить о прошлом), как производить структурный рефакторинг без тестов. В общем, хотя и определение понятия рефакторинга не требует обязательного покрытия кода тестами, я бы его туда записал как постулат. "Рефакторинга без тестов не бывает" )<br>
</div>#7<br>здесь два случая<br></div>1 - только начали учится <br> - сильно замедляет первоначальное время выполнения задачи<br></div> - общее время потраченное на задачу (с учетом будещего времени потраченного на исследования, отладку, правку багов) остается не изменным, либо уменьшается<br>
</div>2 - уже есть опыт использования TDD<br></div> - только ускоряет<br><br></div>Главное не переборщить с тестами, если все длать как пишет Кент Бек в своем труде, то получится каша не поддерживаемого кода. Для обучения да, в реальности - не работает. <br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">22 января 2014 г., 15:21 пользователь Илья Винокуров <span dir="ltr"><<a href="mailto:ilvin@mail.ru" target="_blank">ilvin@mail.ru</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>У вас в объекте есть несколько методов, которые по идеологии юнит тестирования нужно/можно протестировать отдельно.<br>Например: <br><strong>new</strong> - хорошо бы протестировать, что этот метод правильно производит начальную инициализацию переменных в зависимости от переданныех параметров<br>
<strong>set_favicon</strong> - проверить, что устанавливается переменная $self->{ico}<br><strong>listen</strong> - проверить, что сервер действительно начинает слушать нужный сокет. Проверить, что правильно парсятся разные синтаксисы хостов, сервисов. Проверить поведение сервера в ошибочных ситуациях. Проверить, что сокеты переводятся в неблокирующий режим. Проверить поведение метода для разных OS. Проверить, что метод действительно вызывает другой метод prepare.<br>
<strong>accept</strong> - Проверить, что метод вызывается при коннекте клиента. Проверить поведение метода, когда $fn == undef. Проверить, что сокет переводится в неблокирующий режим. А что происходит, если сокет не смог перейти в неблокирующий режим? Проверить, что метод вызывает incoming с правильными аргументами, в зависимости от флага $self->{want_peer}<br>
<br>И так далее по каждому методу.<br><br>Ведь задача юнит тестов - фиксирование интерфейсов взаимодействия разных частей программы. И нужно это для того, чтобы программист сразу видел места, поведение которых изменилось после последнего коммита.<div class="im">
<br><br>> Модуль здесь - AE::HTTP::Server.<br>> тесты проверяют, что этот модуль функционирует корректно.<br><br></div>Ваши тесты проверяют, что модуль в целом функционирует. Относительно всей программы, в которой используется модуль тесты можно назвать юнит-тестами, а вот относительно вашего модуля я назвал ваши тесты функциональными, т.к. вы поставляете только этот модуль...<br>
<br>Или я о каком-то другом виде тестирования говорю?<br><br>Кстати, интересно будет услышать в докладе темы:<br>1) Виды тестирования (в качестве введения в тему)<br>2) Зачем нужны тесты<br>3) Нужно ли тестировать поведение модуля в ситуациях возникновения ошибок<br>
4) До какой степени нужно покрывать тестами код программы.<br>5) Как юнит-тесты помогают в командной разработке<br>6) Как юнит-тесты помогают при рефакторинге кода.<br>7) Как сильно TDD замедляет разработку<br><br>С почтением,<br>
Илья Винокуров<br><br>Среда, 22 января 2014, 13:54 +04:00 от Mons Anderson <<a href="mailto:mons@cpan.org" target="_blank">mons@cpan.org</a>>:<div><div class="h5"><br>
<blockquote style="border-left:1px solid #0857a6;margin:10px;padding:0 0 0 10px">
<div><br>
On 21.01.2014, at 23:18, Илья Винокуров <<a href="http://sentmsg?compose&To=ilvin@mail.ru" target="_blank">ilvin@mail.ru</a>> wrote:<br>
<br>
> <br>
> Да запросто!<br>
> <br>
> Вон у Монса в AnyEvent::HTTP::Server II присутствуют только функциональные тесты, а UNIT тестов нет. Вот давайте и заслушаем доклад, который покажет как писать UNIT тесты для AE. Надеюсь, что в докладе будет подробно расписана техника AE Mock'ов <br>
<br>
А что вы подразмеваете под unit-тестами?<br>
<br>
<br>
> Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.<br>
> Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.<br>
<br>
Модуль здесь - AE::HTTP::Server.<br>
тесты проверяют, что этот модуль функционирует корректно.<br>
<br>
> <br>
> PS: Лично мне этот вопрос очень интересен, если у кого есть ссылки на хорошие методики, поделитесь пожалуйста...<br>
> <br>
> ЗЫ: У меня был опыт покрытия UNIT тестами POE клиента. Тесты для POE писались довольно легко, так как у POE все кишки наружу и в тестах можно было оттрасировать все вызовы колбеков и все аргументы функций. А вот к AnyEvent пока не понятно с какого бока подлезть - у него же все на замыканиях зиждется…<br>
> <br>
<br>
Есть много способов сделать что-нибудь, но опишите, пожалуйста, цель.<br>
<br>
<br>
-- <br>
Moscow.pm mailing list<br>
<a href="http://sentmsg?compose&To=moscow%2dpm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div>
</blockquote>
<br>
<br></div></div><span class="HOEnZb"><font color="#888888">-- <br>Илья Винокуров<br></font></span></div>
<br>--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>С уважением<br>Михаил Шогин.<br>
</div>