У вас в объекте есть несколько методов, которые по идеологии юнит тестирования
нужно/можно протестировать отдельно.
Например:
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 <[email protected]>:
>
>On 21.01.2014, at 23:18, Илья Винокуров < [email protected] > 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
>[email protected] | http://moscow.pm.org
--
Илья Винокуров
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
