<HTML><BODY><p>Иван, в вашей математике нет стоимости ошибки.<br>А стоимость ошибки может быть такая,<br>что даже линейное присвоение значений переменным необходимо проверять,<br>например: на допустимый диапазон значений...<br><br>К тому же вы скромно умолчали о том, как же посчитать покрытие тестами.<br>А посчитать можно с помощью <tt>Devel::Cover</tt>.<br><br><br>С почтением,<br> Илья Винокуров.<br><br><br>Среда, 22 января 2014, 17:30 +04:00 от Ivan Petrov <i.petro.77.00@gmail.com>:<br>
</p><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
<div id="">>> У вас в объекте есть несколько методов, которые по идеологии юнит<br>
>> тестирования нужно/можно протестировать отдельно.<br>
>> Например:<br>
>> new - хорошо бы протестировать, что этот метод правильно производит<br>
>> начальную инициализацию переменных в зависимости от переданныех параметров<br>
<br>
> на такой бред я не буду тратить время.<br>
<br>
+1 <br>
<br>
если у вас в коде написано<br>
<br>
sub foo { return 1 }<br>
<br>
то совершенно не нужен тест<br>
<br>
is foo, 1, 'foo работает как надо';<br>
<br>
это уже удорожание системы тестов совершенно необоснованное.<br>
<br>
вообще от тестов что требуется?<br>
<br>
1. получить от них "обратную связь" о том, что "все работает"<br>
2. получить от них "обратную связь" о том, что при внесении последних<br>
'улучшений' в программу что-то работать перестало<br>
<br>
теперь идем дальше.<br>
<br>
стоимость.<br>
<br>
допустим имеем программу X и тесты к ней Y.<br>
<br>
стоимость написания X - 10 руб (рубли - условная единица!)<br>
стоимость написания Y - 5 руб<br>
<br>
я считаю это где-то с одной стороны оптимумом, а с другой стороны<br>
максимумом стоимости Y.<br>
<br>
оптимум этот еще и в контексте вероятности (которое от покрытия<br>
зависит) обнаружения проблем тестов<br>
<br>
допустим Y обнаруживает проблемы при внесении их в 80% кода, а 20% не<br>
обнаруживает.<br>
вероятность обнаружения проблем (или покрытие) Y при стоимости 1/2<br>
равно 0.8. я считаю это ОЧЕНЬ хорошим покрытием.<br>
<br>
как мне кажется (на основе моего опыта) начиная с уровня покрытия<br>
где-то 60-70% стоимость дополнительного покрытия растет несоизмеримо.<br>
<br>
то есть если у вас отношение стоимости Y/X = 1/2, покрытие при этом 0.6.<br>
то увеличение покрытия с 0.6 до 0.7 зачастую приведет к Y/X == 1.<br>
это _моя_ эмпирика (в основном событийно-ориентированные приложения).<br>
<br>
при покрытии тестами 0.6, если мы вносим одно исправление, то<br>
вероятность обнаружения проблемы считаем тоже 0.6.<br>
вероятность того что мы проблему тоже внесли при этом - 0.5 (по<br>
принципу "встречу динозавра или нет").<br>
тогда в случае если тесты все прошли, то то что выкатка даст сбой в<br>
продакшене - где-то 20%.<br>
<br>
на самом деле на покрытии 0.6 я наблюдаю проблемы где-то в 2% случаев,<br>
то есть видимо принцип "динозавра встречу или нет: 50%" тут наверно не<br>
применим.<br>
<br>
то есть моя оценка: человек делает ошибку в среднем в 2% случаев.<br>
<br>
далее.<br>
если у вас покрытие тестами 0.6, то это покрытие считают обычно<br>
покрытием по алгоритмике. покрытие тестами на "компилируемость" при<br>
общем покрытии 0.6 обычно около единицы.<br>
<br>
интеграционнные тесты.<br>
<br>
с одной стороны это очень хорошая штука (когда есть), а с другой -<br>
обычно очень дорогая.<br>
то есть например имеем http-RPC: сервер, клиент.<br>
<br>
так вот если мы пишем на клиент _самостоятельные_ тесты которые<br>
проверяют протокол, запросы итп, затем пишем _самостоятельные_ тесты<br>
на сервер. то интеграционных тестов у нас вроде бы и нет.<br>
но их написание реально обойдется где-то (опять моя оценка) в 1/2 от<br>
стоимости имеющихся тестов вообще.<br>
при этом мало что даст (то есть на большинстве шагов проблемы будут<br>
находиться самостоятельными тестами в первую очередь и очень редко<br>
интеграционными).<br>
<br>
-- <br>
Moscow.pm mailing list<br>
<a href="sentmsg?compose&To=moscow%2dpm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div>
</blockquote>
<br>
<br>-- <br>Илья Винокуров<br></BODY></HTML>