Как измерить полезность теста?

Тема полезности юниттестов хотя и замусоленна в форумах и книгах,
Но я пока не встречал аргументов в пользу или против них, опирающихся только на фактах.
можно найти аргументы, которые опираются на логические рассуждения в основе которых находятся возможно известные факты, но этого недостаточно.
Так как я сам отношусь очень скептически к юниттестам задался вопросом,
а как измерить полезность конкретного юниттеста? Возможно ли вообще? Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой?

Вообщем, флейм он. Какие будут мысли?

mikron
а как измерить полезность конкретного юниттеста? Возможно ли вообще?

да, можно. тест либо тестирует реализованную функциональность компонента, либо нет. хороший тест является также документацией к использованию компонента. если по тесту непонятно как пользоваться, а как нельзя, это плохой тест.

mikron
Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой?

найти экономическое обоснование можно посчитав цену ошибки.
посчитать время, на устранение багов, на отладку. хорошее покрытие тестами, позволяет очень быстро отлаживать маленькую функциональность. без тестов это сделать невозможно, надо запускать весь проект и тестировать всё сразу, в дебаге.
посчитать время на устранение ошибок, при добавлении или изменение функциональности, ведь никаких инструментов кроме как скомпилировалось или нет у разработчика нет. надо тестировать всё, после любого изменения, вручную. досконально.

а какой-то формулы, типа N тестов умножить на X чего-то там, разделить на Y, и получить рубли/доллары, нет, я не знаю такой формулы.

hVostt
mikron а как измерить полезность конкретного юниттеста? Возможно ли вообще? да, можно.

Вот и хорошо. лозунги и тезисы отправим сразу на свалку истории. Как будем мерять? В каких единицах?

Для начала можно упростить, пусть стоимость единицы времени работы постоянна и не зависит от квалификации. Такой у нас комунизм.
Теперь надо разобратся со стоимостью ошибки.
Задача и з разряда невозможных, но у нас комунизм и ошибку тоже будем мерять в часах работы на устранение её послествий. У нас не АЭС.

Есть исследования, основанные на сравнительной эффективности команд для которых, впрочем, есть критика.

mikron,

как то покрывал тестами разработку c-lib.

нашел очень много ошибок, причем покрытие было не 100%.

написать простой юнит тест простой функции существенно проще, чем выкапывать потом сбой большой программы из-за этой маленькой функции.

измерить разницу затруднительно. я бы оценил в сотни процентов, но опять же - не надо пытаться засунуть в тесты абсолютно всё

затраты на покрытие <100% исходного кода

Другими словами нормируем единицу устранения ошики как 1 час.
Тогда полезность = время устранения последствий стандартной ошибки / врема затраченое на создание и поддержание теста. Верно?

mikron
Другими словами нормируем единицу устранения ошики как 1 час. Тогда полезность = время устранения последствий стандартной ошибки / врема затраченое на создание и поддержание теста. Верно?

Эта формула исходит из того, что тест предотвращает ровно одну ошибку, а это не так.
Еще время устранения ошибки это не все. Ошибку надо:
- Обнаружить
- Воспроизвести (найти условие при котором она вопроизводится)
- Описать
- Поискать в базе нет ли дублей
- Приоритезировать
- Найти root cause
- Исправить
- Проверить исправление (если регрессионное тестирование не автоматизировано то и на регрессии)
- Возможно его документировать
- Развернуть исправление у n клиентов

И пока будет продолжаться этот цикл другие люди будут ее находить у себя тоже и прогонять через часть этого цикла

И еще тесты как документация - наверное надо померить время чтобы разобраться с кодом.
И тесты как средство улучшения дизайна - тут есть всякие метрики типа cyclomatic complexity.

Но это все про хорошие тесты, которые надо уметь готовить

Siemargl
как то покрывал тестами разработку c-lib. нашел очень много ошибок, причем покрытие было не 100%.

во первых, где граница в этом неявном "утверждении полезности" между юнит-тестом и одноразовым тестом? Другими словами, найденые ошибки это "заслуга" теста или юнит-теста? Если потратить время на ручное тестирование, то с ненулевой вероятностью будут так же обнаружены ошибки. ещё не доказано что кодирование и повторное выполнение тестов оправдано.

И второе, ошибки найдены, но ещё не доказана полезность проделанной работы.
Другими словами, кого волнуют ошибки, если они никогда не проявляются?

WebSharper
Но это все про хорошие тесты, которые надо уметь готовить

Довайте оставим категории "хорошие" и "плохие" как субьективные, и попробуем определится с объективными критериями оценки.

Так как человек в основе существо разумное (хочется верить) то и делает оно только то что разумно оправдывает затраты на усилия.