Иван, этот текст еще облагородить, дополнить примерами - и готовый доклад.
22.01.2014, 17:30, "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
