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

[Ivan Petrov]

>> У вас в объекте есть несколько методов, которые по идеологии юнит
>> тестирования нужно/можно протестировать отдельно.
>> Например:
>> 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 от
стоимости имеющихся тестов вообще.
при этом мало что даст (то есть на большинстве шагов проблемы будут
находиться самостоятельными тестами в первую очередь и очень редко
интеграционными).