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

Михаил Шогин mshogin на gmail.com
Чт Янв 23 05:15:37 PST 2014 

#3 ответ да
  У нас принято так
    - как минимум два позитивных теста ( коректное поведение потока
выполнения)
    - как минимум один тест на каждый случай неготивного поведения
#4 после #3 как минимум один тест на каждый баг. при таком подходе покрытие
будет более 80%, что позволяет "ВАЩЕ_НЕ_ПАРИТСЯ_И_СПАТЬ_СПОКОЙНО"
#5 В контексте командной разработки, самое лучшее это
  - тесты документация кода
  - хороший отпуск, код может легко править любой член команды
  - безопастность смены члена команды
#6 Без тестов рефакторить могут только ГУРУ-ЗУБРЫ. Я к тамим не отношусь,
так что рискнуть отрефакторить что нить на комерческом проекте 24/7/365 не
отважусь, даже при аппруве всего руководства и повышении зп в 2 раза :)
 А если на пальцах, то
  - есть ограниченное количество рефакторингов которые безопастно делать
без покрытия тестами. Например рефакторинг "Change Method Signature", очень
просто делать в компилируемых ЯП, но не безопастно в динамических. Однако,
я не представляю себе (в настоящий момент, не будем говорить о прошлом),
как производить структурный рефакторинг без тестов. В общем, хотя и
определение понятия рефакторинга не требует обязательного покрытия кода
тестами, я бы его туда записал как постулат. "Рефакторинга без тестов не
бывает"  )
#7
здесь два случая
1 - только начали учится
   - сильно замедляет первоначальное время выполнения задачи
   - общее время потраченное на задачу (с учетом будещего времени
потраченного на исследования, отладку, правку багов) остается не изменным,
либо уменьшается
2 - уже есть опыт использования TDD
   - только ускоряет

Главное не переборщить с тестами, если все длать как пишет Кент Бек в своем
труде, то получится каша не поддерживаемого кода. Для обучения да, в
реальности - не работает.


22 января 2014 г., 15:21 пользователь Илья Винокуров <ilvin на mail.ru>написал:

>
> У вас в объекте есть несколько методов, которые по идеологии юнит
> тестирования нужно/можно протестировать отдельно.
> Например:
> *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<http://sentmsg?compose&To=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://sentmsg?compose&To=moscow%2dpm@pm.org> |
> http://moscow.pm.org
>
>
>
> --
> Илья Винокуров
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20140123/d3345f97/attachment.html>

Подробная информация о списке рассылки Moscow-pm