Я согласен с тем, что написал Эндрю, но хотел добавить к ответу другую точку зрения, которую, как мне кажется, довольно часто упускают. в таких обсуждениях.
Ваша команда создает продукт, и ваша компания хочет получить от этого наилучшее соотношение цены и качества.
Вначале вы можете подумать, что тесты замедляют работу — ваша система проста и всем понятна, так что зачем тратить время. Может показаться, что вы получаете мало пользы от написания тестов. Но это явно неправильно, если вы придерживаетесь более долгосрочного взгляда на разработку своего продукта. Но я остановлюсь здесь, так как я проповедую обращенным.
Однако, если вы примете такое же мышление, пытаясь ответить на свой вопрос, вы увидите, что на самом деле ответ во многом зависит от ваших обстоятельств. Я собираюсь использовать довольно упрощенную математическую модель, чтобы объяснить свои мысли:
Пусть P(bug | test) обозначает вероятность bug при условии, что вы запускаете test, пусть C(test) обозначает стоимость выполнения теста, а C(bug) обозначает стоимость ошибки.
Если вы сосредоточитесь на конкретной ошибке*, вы хотите свести к минимуму следующее:
P(bug | test_1)*C(bug) + C(test_1) ... P(bug | test_n)*C(bug) + C(test_n)
Где ваш набор состоит из n тестов.
Если бы вы не принимали во внимание стоимость тестов, очевидно, что чем больше у вас тестов, тем лучше, верно? Но поскольку тесты необходимо поддерживать, выполнять и т. д., они имеют ненулевую стоимость. Это означает, что у вас есть компромисс, и, в конце концов, вы выполняете U-образную оптимизацию здесь (немного похоже на этот изображение, где они пытаются найти оптимальный компромисс между затратами на выпуск и хранение).
Фактические затраты во многом зависят от конкретной области, областей продукта и типов тестов.
Если вы работаете в банковской сфере, стоимость ошибки может быть огромной, поэтому затраты на тестирование будут ничтожными. Но если вы пишете рекомендательный движок для музыки, наличие предложений, отключенных в течение нескольких часов, не будет проблемой. На самом деле, в последнем случае вам, вероятно, нужна свобода экспериментировать с различными алгоритмами и возможность быстро выполнять итерации, поэтому стоимость теста может превысить стоимость ошибки.
Допустим, вы работаете над определенным продуктом. Даже это не однородно. Будут области вашего продукта, которые являются более важными, чем другие. Возьмем, к примеру, твиттер: если человек не может твитнуть или загрузить твиты того, за кем он следит, это будет большой проблемой. С другой стороны, если пусто указать, кому следовать предложениям, влияние на продукт будет намного меньше.
Наконец, стоимость тестов также неодинакова. Но, как я уже говорил ранее, это не является незначительным, и его нужно учитывать с осторожностью. Я работал как в местах, где плохое тестовое покрытие замедляло работу команд, потому что им не хватало уверенности, чтобы внедрить свои изменения в производство, так и в местах, где запуски тестов были настолько длинными, что люди жаловались, что они постоянно строят и почти не работают.
Последняя вещь. Хорошо строить с учетом устойчивости к сбоям — это снизит для вас стоимость ошибок.
person
velocipedist
schedule
06.05.2014
