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

Если бы все было так просто

За каждым модным новым подходом стоит предположение, что новый подход может быть реализован идеально. Однако, учитывая давление, с которым сталкиваются команды разработчиков, мы должны начать думать над вопросом: что достаточно хорошо, чтобы обеспечить отдачу? Давайте обратимся к нашему набору автоматизированных тестов, который является неотъемлемой частью ускорения наших процессов разработки. Чего мы пытаемся достичь? Мы хотим, чтобы каждая сборка проходила самотестирование, т. е. давала нам чистую справку о работоспособности (или сообщала о проблеме). Сообщить о проблемах очень просто: если тест не пройден, сборка помечается как неисправная, и люди могут немедленно изучить ее.

Получить чистое свидетельство о здоровье после прохождения сборки гораздо сложнее. Мы пытаемся доказать отсутствие багов. Поэтому мы можем считать идеальным набором тестов тот, в котором, если сборка проходит успешно, в программном обеспечении нет ошибок. Однако это благородная цель, такая же важная, как попытка доказать, что инопланетян не существует.

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

Вместо того, чтобы рационализировать решение не писать тесты из-за нехватки времени, как насчет того, чтобы спросить себя: есть ли у меня время написать один тест? Если ответ да, то напишите этот один тест. И продолжайте, пока не истечет время. Это правда, что это не приведет к идеальному набору тестов. Но как говорит Мартин Фаулер: Несовершенные тесты лучше совершенных тестов, которые никогда не пишутся.

Слишком часто из-за неудачных тестов между командами возникает перетягивание каната. Команды спрашивают: тесты неверны или код неверен? Если мы перестанем думать о неудачных тестах и ​​вместо этого подумаем о тестах, сообщающих об изменениях в продукте, то вместо того, чтобы искать виноватых, мы сможем решить, желательны ли эти изменения или нет.

Если бы у нас было свободное полчаса каждый день, мы все могли бы написать новый тест и постепенно повышать общее качество кода. Помните: тест не обязательно должен быть идеальным; он просто должен быть достаточно хорош, чтобы выделить проблему, когда она терпит неудачу.

Вас также может заинтересовать: