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

Илья Винокуров ilvin на mail.ru
Ср Янв 22 05:57:32 PST 2014


Иван, в вашей математике нет стоимости ошибки.
А стоимость ошибки может быть такая,
что даже линейное присвоение значений переменным необходимо проверять,
например: на допустимый диапазон значений...

К тому же вы скромно умолчали о том, как же посчитать покрытие тестами.
А посчитать можно с помощью  Devel::Cover .


С почтением,
  Илья Винокуров.


Среда, 22 января 2014, 17:30 +04:00 от 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


-- 
Илья Винокуров
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20140122/3279f28c/attachment-0001.html>


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