Автоматизированные тесты — это не только следование лучшим практикам. Это оказывает реальное влияние на вашу компанию.
Существует множество причин, по которым вам следует использовать автоматические тесты для вашего программного обеспечения. Проблема в том, что некоторые из них не так очевидны для всех. От неопытного или самоуверенного разработчика до менеджера команды написание тестов может показаться еще одной тривиальной, необязательной задачей.
Даже те, кто утверждают, что понимают важность наличия надежного набора тестов, по-прежнему предпочитают пренебрегать задачей, а не другими, на первый взгляд, более срочными вещами. В конце концов, легко поддаться давлению, связанному с запуском определенных вещей или постоянно растущей кучи новых функций, ожидающих реализации, и сказать:
«Мы напишем тесты позже».
Конечно, так никогда не бывает. Рынок со временем меняется, как и потребности ваших клиентов и требования вашего приложения. Это, в свою очередь, приводит к запросу на новые функции. Нижняя граница? Вы никогда не получите то дополнительное время, которое, как вы думали, у вас будет.
Сейчас можно подумать:
«Но написание тестов требует времени! Написание тестов для будущих функций также потребует времени! Не замедлит ли это процесс разработки?».
Ну, для начала, это самый распространенный аргумент против написания тестов. Ответ гораздо сложнее, чем просто да или нет. Так что потерпите меня немного.
Трудоемкое ручное тестирование
Написание тестов требует времени. Но то же самое происходит и с ручным тестированием… снова и снова… каждый раз, когда вы вносите изменения! Если вам посчастливилось быть разработчиком, вы, вероятно, уже знаете, что средний случай разработки без тестов будет выглядеть следующим образом:
Вам поручили внедрить новую функцию. Вы начинаете с чтения требований, затем изучаете соответствующий код и разрабатываете реализацию. Некоторые даже набросают свою документацию на этом этапе. Все готово для самой интересной части: написания кода. Наконец, через некоторое время вы завершаете реализацию.
Довольно часто ваша реализация требует от вас внесения нескольких изменений тут и там, а это значит, что теперь вам нужно протестировать существующую функциональность, чтобы убедиться, что ваши изменения ничего не сломали. Для простоты предположим, что на этот раз вам повезло. Вы протестировали существующую функциональность, и все по-прежнему работало, как ожидалось.
Вы продолжаете тестирование новой функциональности. Через несколько мгновений вы понимаете, что что-то работает не так, как должно. Вы возвращаетесь к коду, меняете несколько строк и начинаете тестирование заново. Это повторяется довольно много раз, пока вы не сделаете все правильно, и вам придется перезапускать процесс тестирования снова и снова.
Автоматизированные тесты в помощь
Теперь давайте рассмотрим тот же сценарий, если бы присутствовали автоматические тесты. Первые шаги одинаковы: чтение требований, изучение соответствующего кода и разработка реализации перед написанием кода. Пока ничего не изменилось.
Далее, вместо того, чтобы писать фактическую реализацию, вы начинаете с написания теста для небольшой части функциональности. Этот тест потерпит неудачу, если вы запустите свои тесты. Затем вы пишете фактическую реализацию, чтобы этот конкретный тест прошел.
Если все тесты пройдены, вы продолжаете аналогичным образом. Вы пишете новый тест или улучшаете существующий, который изначально не работает, а затем пишете код, удовлетворяющий этому тесту.
Если вы внесли какие-либо изменения в существующую функциональность, все, что вам нужно сделать, это просто запустить все или часть ранее существовавших тестов. Тесты быстро дадут вам знать, если, почему и где что-то сломалось. Когда вы, наконец, закончите программировать, вы можете протестировать функцию вручную, чтобы убедиться, что ничего не ускользнуло.
Гораздо продуктивнее, вам не кажется? Этот процесс известен как разработка через тестирование (TDD).
Джейсон Горман провел эксперимент, в ходе которого написал программу для преобразования целых чисел в римские цифры. Он повторял это действие шесть дней подряд.
В первый, третий и пятый дни он использовал TDD. В остальные дни он не использовал TDD. Результаты показали, что в дни TDD процесс разработки был примерно на 10 % быстрее, чем в дни без TDD.
Помимо того, что вы сэкономите время, это подчеркивает еще одно преимущество автоматизированных тестов: ваша команда разработчиков не устанет от утомительного повторяющегося процесса ручного тестирования!
Усилия и время, сэкономленные вашими автоматическими тестами, теперь можно использовать для более важных вещей, таких как внедрение новых функций или рефакторинг и улучшение вашего кода.
Рефакторинг и автоматизированные тесты
Несмотря на все усилия, в вашем коде рано или поздно возникнет технический долг. Если ее не решить, она будет накапливаться медленно, но верно, резко увеличивая стоимость внесения изменений в ваш код и снижая производительность вашей команды в долгосрочной перспективе. Неизбежно, в какой-то момент вам придется реорганизовать свой код. Код, который нельзя рефакторить, обречен на упадок и гниение.
Поэтому рефакторинг является ценным инструментом. Но он также может быть опасным, если не используется должным образом. Написание кода без тестов для совершенно новой функции — это одно. Рефакторинг кода, написанного кем-то другим месяцы или даже годы назад, — это совсем другая история.
Чтобы правильно провести рефакторинг, вам нужен надежный набор тестов для немедленного обнаружения критических изменений. Как только вы обнаружите критические изменения в своих тестах, вы можете принять меры, чтобы избежать дальнейшего сбоя.
Другими словами, автоматические тесты позволяют реорганизовать ваш код, улучшить качество вашего кода и, таким образом, косвенно улучшить ваш продукт (или услугу). Они позволяют вашему коду выдержать испытание временем (каламбур).
Необнаруженные ошибки: невидимая угроза
Повторяющееся ручное тестирование плохо не только потому, что оно трудоемко и утомит ваших разработчиков, но и потому, что оно «забывчиво». Нереально ожидать, что кто-то запомнит все тестовые примеры наизусть. В конце концов, один или несколько случаев ускользают и освобождают место для ошибок, которые незамеченными переходят в производственную версию.
Написав тесты, вы документируете и сохраняете тестовые примеры для использования в будущем. Они будут там, когда они вам понадобятся. Тесты не могут быть на 100% «написаны один раз, используются навсегда», так как вам, вероятно, потребуется обновлять их всякий раз, когда вы вносите изменения в соответствующую реализацию. Но это ничто по сравнению с запуском с нуля каждый раз, когда вы хотите протестировать часть или все приложение.
Необнаруженные ошибки могут стать настоящим разочарованием и кошмаром. Особенно, если вы достигли точки, когда добавление новой функции или исправление обнаруженной ошибки приводит к появлению множества необнаруженных ошибок.
Без тестов вы полагаетесь на людей, которые проводят тестирование, а мы, люди, делаем ошибки гораздо чаще, чем нам хотелось бы признать.
Доброе имя дороже золота
В конце концов, все сводится к имени и репутации компании. Если ошибки могут остаться незамеченными и попасть в вашу продукцию, некоторые из них могут быть достаточно серьезными, чтобы нанести ущерб репутации вашей компании. Излишне говорить, что нет ничего хуже, чем иметь дело с такими ситуациями.
Клиенты платят за продукт или услугу и ожидают, что они заслуживают доверия. Они ожидают получить отдачу от денег, которые они вкладывают. Но вы решили поставить под угрозу свою надежность в тот момент, когда решили поставить тесты на второе место. Какой ценой? А для чего?
Заключение
Большая ложь, которую можно купить, заключается в том, что отказ от написания тестов сэкономит время или ускорит процесс, даже в краткосрочной перспективе. Но в разработке программного обеспечения нет такого компромисса между качеством и скоростью.
Автоматизированные тесты — это не только следование лучшим практикам. Это оказывает реальное влияние на вашу компанию. Это влияет на производительность и уверенность вашей команды, качество кода вашего приложения, а также на репутацию и благополучие вашей компании.
