[Moscow.pm] Встреча Moscow.pm в феврале

[Илья Винокуров]

У вас в объекте есть несколько методов, которые по идеологии юнит тестирования нужно/можно протестировать отдельно.
Например: 
new - хорошо бы протестировать, что этот метод правильно производит начальную инициализацию переменных в зависимости от переданныех параметров
set_favicon - проверить, что устанавливается переменная $self->{ico}
listen - проверить, что сервер действительно начинает слушать нужный сокет. Проверить, что правильно парсятся разные синтаксисы хостов, сервисов. Проверить поведение сервера в ошибочных ситуациях. Проверить, что сокеты переводятся в неблокирующий режим. Проверить поведение метода для разных OS. Проверить, что метод действительно вызывает другой метод prepare.
accept - Проверить, что метод вызывается при коннекте клиента. Проверить поведение метода, когда $fn == undef. Проверить, что сокет переводится в неблокирующий режим. А что происходит, если сокет не смог перейти в неблокирующий режим? Проверить, что метод вызывает incoming с правильными аргументами, в зависимости от флага $self->{want_peer}

И так далее по каждому методу.

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

> Модуль здесь - AE::HTTP::Server.
> тесты проверяют, что этот модуль функционирует корректно.

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

Или я о каком-то другом виде тестирования говорю?

Кстати, интересно будет услышать в докладе темы:
1) Виды тестирования (в качестве введения в тему)
2) Зачем нужны тесты
3) Нужно ли тестировать поведение модуля в ситуациях возникновения ошибок
4) До какой степени нужно покрывать тестами код программы.
5) Как юнит-тесты помогают в командной разработке
6) Как юнит-тесты помогают при рефакторинге кода.
7) Как сильно TDD замедляет разработку

С почтением,
  Илья Винокуров

Среда, 22 января 2014, 13:54 +04:00 от Mons Anderson <mons на cpan.org>:
>
>On 21.01.2014, at 23:18, Илья Винокуров < ilvin на mail.ru > wrote:
>
>> 
>> Да запросто!
>> 
>> Вон у Монса в AnyEvent::HTTP::Server II присутствуют только функциональные тесты, а UNIT тестов нет. Вот давайте и заслушаем доклад, который покажет как писать UNIT тесты для AE. Надеюсь, что в докладе будет подробно расписана техника AE Mock'ов 
>
>А что вы подразмеваете под unit-тестами?
>
>
>> Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
>> Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
>
>Модуль здесь - AE::HTTP::Server.
>тесты проверяют, что этот модуль функционирует корректно.
>
>> 
>> PS: Лично мне этот вопрос очень интересен, если у кого есть ссылки на хорошие методики, поделитесь пожалуйста...
>> 
>> ЗЫ: У меня был опыт покрытия UNIT тестами POE клиента. Тесты для POE писались довольно легко, так как у POE все кишки наружу и в тестах можно было оттрасировать все вызовы колбеков и все аргументы функций. А вот к AnyEvent пока не понятно с какого бока подлезть - у него же все на замыканиях зиждется…
>> 
>
>Есть много способов сделать что-нибудь, но опишите, пожалуйста, цель.
>
>
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org


-- 
Илья Винокуров
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20140122/18e88b22/attachment.html>