Frontend-тестирования на крупных проектах

Источник: Some Bugs, Amazon

Unit-тесты

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

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

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

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

Например, в 2014 году через баг цена на весь ассортимент товаров на сайте Screwfix стала одинаковой — 34,99 фунтов, благодаря чему покупатели смогли покупать инструменты с существенной «скидкой», а в 2011 году контракт с оператором T-Mobile можно было подписать бесплатно, чем и воспользовалось 2 тысячи пользователей.

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

Также разработчика может подвести уверенность в том, что он все учел. Для таких багов также очень полезны unit-тесты. Раз написал тесты, после каждой смены запустил их, и, если ничего не упало, то молодец. А если есть ошибки, то быстренько исправил — и все прекрасно.

Интеграционные тесты

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

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

“e2e”

Кроме того, для тестирования взаимодействия всех компонентов в целом используются end to end tests, которые более широко тестируют работу всей системы.

Пример для фронтенда: есть форма для заполнения определенных данных. Наши ” e2e ” – тесты загрузят страницу и понажимают разные кнопки, введут данные и проверят, все в целом пройдет по спланированному сценарию.

А давайте все покроем ” e2e ” -тестами!

Казалось бы, ” e2e ” -тесты идеальны, если посмотреть на них с точки зрения теории. С их помощью можно протестировать все варианты взаимодействия пользователя и интерфейса и выявить баги еще на ранних этапах. Даже и мысль мелькнет, что больше тестов никаких не нужно, только ” e2e ” -тесты, ибо с ними и так можно выявить все дефекты, явные для пользователя.

Это отчасти верно, но на практике крупные компании (даже Google) столкнулись с тем, что ” e2e ” для разработки очень не удобны, потому что одна из задач — это выявить баг, а другая — его исправить. Для фиксов необходимо знать, где именно возник баг, в какой части кода, и поскольку ” e2e ” — обобщающие тесты, они не способны предоставить детальную информацию. Именно через это Google в своей статье Just Say No to More End-to-End Tests предлагает следующую пропорцию использования различных видов тестов:

70/20/10. 70% unit-тестов, 20% integration и 10% “e2e”. Из этого можно сделать вывод, что чем легче разработчику выявить баг, тем меньше времени на него потратится, и сам фикс будет более корректным. Мы же будем иметь достаточно информации о баг, а это ускорит релиз и сэкономит средства, которые тратятся на разработку программного продукта.

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

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

Большим проектам — большие тесты

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

Хотите стать Front End разработчиком уже сегодня? Ознакомьтесь с нашей программой курса и можете записаться уже сегодня!