[Moscow.pm] Встреча Moscow.pm в феврале
Mons Anderson
mons на cpan.org
Ср Янв 22 04:53:18 PST 2014
On 22.01.2014, at 15:21, Илья Винокуров <ilvin на mail.ru> wrote:
>
> У вас в объекте есть несколько методов, которые по идеологии юнит тестирования нужно/можно протестировать отдельно.
> Например:
> new - хорошо бы протестировать, что этот метод правильно производит начальную инициализацию переменных в зависимости от переданныех параметров
на такой бред я не буду тратить время.
> set_favicon - проверить, что устанавливается переменная $self->{ico}
а если я решу переписать механизм? проверять нужно, что после set_favicon запрос на /favicon возвращает то, что нужно (т.е. опять-же - функционал)
> listen -
> проверить, что сервер действительно начинает слушать нужный сокет.
ок, допустим.
> Проверить, что правильно парсятся разные синтаксисы хостов, сервисов.
это функционал другого модуля
> Проверить поведение сервера в ошибочных ситуациях.
возможно
> Проверить, что сокеты переводятся в неблокирующий режим.
зачем?
проверять вызов fh_nonblocking $fh, 1;?
может быть начнём еще проверять, что вызов print "hello world" отрабатывает как нужно?
> Проверить поведение метода для разных OS.
> Проверить, что метод действительно вызывает другой метод prepare.
там код линейный. как он может его не вызывать?
> accept - Проверить, что метод вызывается при коннекте клиента.
> Проверить поведение метода, когда $fn == undef.
это неконсистентное состояние объекта
> Проверить, что сокет переводится в неблокирующий режим.
> А что происходит, если сокет не смог перейти в неблокирующий режим?
это как?
> Проверить, что метод вызывает incoming с правильными аргументами, в зависимости от флага $self->{want_peer}
чтобы это проверить эти 5 строк, в которых негде ошибиться, нужно написать строк 50 теста. зачем?
>
> И так далее по каждому методу.
Какие-то вещи, несомненно, имеют смысл, но на большинство мне жаль тратить время.
какие-то из описываемых кейсов предполагают влезание внутрь объекта.
если вы из автомобиля выкрутить 1 свечу или открутите колесо, вы предполагаете, что машина корректно обработает эту ситуацию?
>
> Ведь задача юнит тестов - фиксирование интерфейсов взаимодействия разных частей программы.
вот именно, программы.
модуль обязан соблюдать только внешний интерфейс.
внутренности я могу переписывать как угодно.
и тестировать внутреннее взаимодействие не вижу смысла.
> И нужно это для того, чтобы программист сразу видел места, поведение которых изменилось после последнего коммита.
>
> > Модуль здесь - AE::HTTP::Server.
> > тесты проверяют, что этот модуль функционирует корректно.
>
> Ваши тесты проверяют, что модуль в целом функционирует. Относительно всей программы, в которой используется модуль тесты можно назвать юнит-тестами, а вот относительно вашего модуля я назвал ваши тесты функциональными, т.к. вы поставляете только этот модуль...
>
> Или я о каком-то другом виде тестирования говорю?
>
> Кстати, интересно будет услышать в докладе темы:
> 1) Виды тестирования (в качестве введения в тему)
> 2) Зачем нужны тесты
> 3) Нужно ли тестировать поведение модуля в ситуациях возникновения ошибок
> 4) До какой степени нужно покрывать тестами код программы.
> 5) Как юнит-тесты помогают в командной разработке
> 6) Как юнит-тесты помогают при рефакторинге кода.
> 7) Как сильно TDD замедляет разработку
>
В общем про тесты и документацию это не ко мне )
по документации мой ответ - код лучшая документация.
про тесты - уже написал выше.
могу, разве что, придумать по просьбе сообщества механизмы для тестирования AE
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20140122/cf469e3b/attachment.html>
Подробная информация о списке рассылки Moscow-pm