Почему тесты должны быть быстрыми

Немного о программировании.

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

— А еще, когда я задачу доделаю, наши тесты должны стать заметно быстрее.

Но вместо того, чтобы поклониться мне в ноги и назвать спасителем, вождь заявляет дословно следующее:

— А мне не важно, чтобы они были быстрыми. Мне важно, чтобы они были надежными.

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

Но почему тесты должны быть быстрыми? Почему для меня скорость — более важная проблема, чем надежность? Так ли оно на самом деле? Подсознание поработало сутки, и выдало новую теорию всего и почему я снова прав.

2-3 процента из примерно 750 наших интеграционных тестов действительно ненадежны, и регулярно выдают ложные срабатывания. Если бы это были тесты не беременность, то по стране ходили бы полчища седых девушек. Чтобы это как-то обойти, сервер запускает такие тесты по нескольку раз, и только тогда, когда они ни разу не отработали нормально, считает их действительно упавшими. Сколько бы мы их не чистили, процент проблемных тестов остается на одном и том же уровне.

Я объясняю это тем, что наши тесты очень сложно писать и поддерживать. В первую очередь из-за того, что они невероятно медленные. С 2010-го года,  когда мы начали тестировать вэб часть проекта, ни наши подходы, ни наши инструменты не изменились никак. И это странно, ведь живой код обычно развивается, эволюционирует, исправляются одни ошибки, добавляются другие. Но не у нас. Где-то недавно встретил мысль, что эволюция и обучение идут максимально эффективно, когда есть быстрая обратная связь. В нашем случае обратная связь иногда приходит минуты через полторы, после запуска теста. Серьезно. Я сегодня подправил тест, начал его отлаживать, и Visual Studio весело поморгала окошками с минуту, прежде чем открыть браузер. А потом, собственно, началась отладка. Но я уже забыл, что собирался делать.

Никому не нравится то, как написаны наши тесты. Но с той скоростью, с которой проходит цикл «что-то подправить — посмотреть на результат», любой нормальный человек остановится на самом простом решении, потому что работы еще уйма, а это «всего лишь» тест. Мне приходится сильно напрягать волю, чтобы не останавливаться на первом сработавшем решении и как-то приводить тест в удобоваримый вид, потому что это занимает дополнительную прорву времени и постоянно ускользающий фокус внимания.

Сколько бы мы не отлаживали ненадежные тесты, всегда будут появляться новые, потому что код проекта как раз-таки эволюционирует, а тесты — нет.

Я понимаю, что для бизнеса скорость — менее очевидная проблема, чем надежность, но причинно-следственную связь тоже не стоит сбрасывать со счетов. Это как клеить пятки пластырем, потому что колется, но игнорировать битое стекло на полу.

В общем, пойду завтра продолжать спор. Если меня уволят, то с радостью приму предложения работы в Европе.