On 22.01.2014, at 15:21, Илья Винокуров <[email protected]> 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
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
