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

Владимир Затолока me на spidamoo.ru
Ср Янв 22 05:46:30 PST 2014


Иван, этот текст еще облагородить, дополнить примерами - и готовый доклад.

22.01.2014, 17:30, "Ivan Petrov" <i.petro.77.00 на gmail.com>:
>>>  У вас в объекте есть несколько методов, которые по идеологии юнит
>>>  тестирования нужно/можно протестировать отдельно.
>>>  Например:
>>>  new - хорошо бы протестировать, что этот метод правильно производит
>>>  начальную инициализацию переменных в зависимости от переданныех параметров
>>  на такой бред я не буду тратить время.
>
> +1
>
> если у вас в коде написано
>
> sub foo { return 1 }
>
> то совершенно не нужен тест
>
> is foo, 1, 'foo работает как надо';
>
> это уже удорожание системы тестов совершенно необоснованное.
>
> вообще от тестов что требуется?
>
> 1. получить от них "обратную связь" о том, что "все работает"
> 2. получить от них "обратную связь" о том, что при внесении последних
> 'улучшений' в программу что-то работать перестало
>
> теперь идем дальше.
>
> стоимость.
>
> допустим имеем программу X и тесты к ней Y.
>
> стоимость написания X - 10 руб (рубли - условная единица!)
> стоимость написания Y - 5 руб
>
> я считаю это где-то с одной стороны оптимумом, а с другой стороны
> максимумом стоимости Y.
>
> оптимум этот еще и в контексте вероятности (которое от покрытия
> зависит) обнаружения проблем тестов
>
> допустим Y обнаруживает проблемы при внесении их в 80% кода, а 20% не
> обнаруживает.
> вероятность обнаружения проблем (или покрытие) Y при стоимости 1/2
> равно 0.8. я считаю это ОЧЕНЬ хорошим покрытием.
>
> как мне кажется (на основе моего опыта) начиная с уровня покрытия
> где-то 60-70% стоимость дополнительного покрытия растет несоизмеримо.
>
> то есть если у вас отношение стоимости Y/X = 1/2, покрытие при этом 0.6.
> то увеличение покрытия с 0.6 до 0.7 зачастую приведет к Y/X == 1.
> это _моя_ эмпирика (в основном событийно-ориентированные приложения).
>
> при покрытии тестами 0.6, если мы вносим одно исправление, то
> вероятность обнаружения проблемы считаем тоже 0.6.
> вероятность того что мы проблему тоже внесли при этом - 0.5 (по
> принципу "встречу динозавра или нет").
> тогда в случае если тесты все прошли, то то что выкатка даст сбой в
> продакшене - где-то 20%.
>
> на самом деле на покрытии 0.6 я наблюдаю проблемы где-то в 2% случаев,
> то есть видимо принцип "динозавра встречу или нет: 50%" тут наверно не
> применим.
>
> то есть моя оценка: человек делает ошибку в среднем в 2% случаев.
>
> далее.
> если у вас покрытие тестами 0.6, то это покрытие считают обычно
> покрытием по алгоритмике. покрытие тестами на "компилируемость" при
> общем покрытии 0.6 обычно около единицы.
>
> интеграционнные тесты.
>
> с одной стороны это очень хорошая штука (когда есть), а с другой -
> обычно очень дорогая.
> то есть например имеем http-RPC: сервер, клиент.
>
> так вот если мы пишем на клиент _самостоятельные_ тесты которые
> проверяют протокол, запросы итп, затем пишем _самостоятельные_ тесты
> на сервер. то интеграционных тестов у нас вроде бы и нет.
> но их написание реально обойдется где-то (опять моя оценка) в 1/2 от
> стоимости имеющихся тестов вообще.
> при этом мало что даст (то есть на большинстве шагов проблемы будут
> находиться самостоятельными тестами в первую очередь и очень редко
> интеграционными).
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением, Владимир Затолока


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