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

[Mons Anderson]

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>