Почему мы тестируем – делаем все быстрее с помощью разработки, управляемой тестированием

1656657614 pochemu my testiruem – delaem vse bystree s pomoshhyu razrabotki

автор Райнер Ганекамп

mMHXwpchQBIjZznUiyKOehx2SFJyf3FMunBC
Фотография Эрленда Эксета на Unsplash

Как мы все знаем, модульные тесты дают нам определенную сетку безопасности. Они дают нам программу, с помощью которой мы можем проверить, работает ли система правильно — особенно после того, как мы вносим изменения или расширения.

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

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

Вы можете подумать, что ручная проверка быстрая

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

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

  • 10-секундная загрузка
  • 5-секундный сборник
  • 5-секундная перезагрузка и тестирование

Итак, у нас уже есть 20 секунд для ручной проверки. Это предполагает, что ваши клиентские и серверные сборочные инструменты, такие как Webpack и Maven, оптимизированы.

1XdNOR82xVsdoCNIlgGw7khYRfNi2RWod0rN
Ручные проверки требуют больше времени, чем вы думаете

Но проверки продолжаются дольше, чем вы думаете

Однако зачастую другие вещи значительно продлевают время проверки. Иногда мы, разработчики, упускаем ошибки во время первого запуска. А во втором. (Или третий!) Каждый из них умножает время, которое вы тратите на проверку кода.

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

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

TDD ускоряет работу

Правильная разработка, управляемая тестированием (TDD) – сначала написание теста, а затем код – дает вам преимущество, благодаря которому вы можете запустить практически любую конкретную часть изолированного кода за считанные секунды.

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

Замена ручной проверки этими тестами значительно увеличивает скорость. Вы также получаете код лучшего качества, но об этом позже. Последний запуск проверки будет ручным. Именно здесь вы фактически проверяете, все ли так, как они должны быть как конечный пользователь в обозревателе.

Да, даже для тех особых случаев

Вы всегда можете придумать некоторые ситуации, когда вы считаете, что применение TDD совершенно глупо.

Подумайте о том, что я называю «экспериментальной работой» – методом проб и ошибок, который вам нужно выполнить, чтобы узнать, как пользоваться библиотекой или услугой, с которой вы не слишком знакомы. Вы уже работаете с неизвестным компонентом. Зачем усложнять это, добавляя уровень тестовой базы вокруг основного кода?

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

В обоих случаях вам следует использовать TDD с самого начала. Создание модульных тестов для «экспериментальной работы» позволяет быстрее выполнить часть проб и ошибок и предоставляет вам набор инструментов, к которому вы всегда можете вернуться позже. Ваш код «перемещение данных из базы данных в браузер» будет расти, что приведет к тому, что кодовая база, не подлежащая проверке, не сможет запускать части кода изолированно друг от друга. Вам придется проделать трудоемкие ручные тесты самостоятельно.

TDD стоит усилий

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

Правильное написание модульных тестов – это навык, который вы обычно не получаете в университетах или на обычных курсах программирования. Это сложно с первого раза(ов), и понадобится несколько часов, чтобы привыкнуть, но вы скоро увидите первые результаты и никогда не будете оглядываться назад.

Экономьте время, инвестируя в качественные модульные тесты с самого начала, и начинайте с модульной программы с первого комита.

Впервые опубликовано на www.rainerhahnekamp.com 15 марта 2017 года.

Добавить комментарий

Ваш адрес email не будет опубликован.