Иван, в вашей математике нет стоимости ошибки. А стоимость ошибки может быть такая, что даже линейное присвоение значений переменным необходимо проверять, например: на допустимый диапазон значений...
К тому же вы скромно умолчали о том, как же посчитать покрытие тестами. А посчитать можно с помощью Devel::Cover . С почтением, Илья Винокуров. Среда, 22 января 2014, 17:30 +04:00 от Ivan Petrov <[email protected]>: >>> У вас в объекте есть несколько методов, которые по идеологии юнит >>> тестирования нужно/можно протестировать отдельно. >>> Например: >>> 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 >[email protected] | http://moscow.pm.org -- Илья Винокуров
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
