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

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

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

История двух команд и их накопившихся ошибок

Сегодняшняя история начинается в конце 2017 года с командами «Доски идей» и «Планировщик комнат». Этим командам принадлежат функции, которые позволяют нашим клиентам сохранять продукты, которые они рассматривают как покупку, а также инструмент, который позволяет им визуализировать продукты в пространстве виртуальной комнаты, соответственно.

Примерно шесть месяцев назад разработчики сосредоточились на написании минимального количества кода, необходимого для работы и развертывания функций. К концу 2017 года наша очередь выросла и насчитывала почти 70 активных ошибок. Наши команды испробовали различные стратегии, чтобы уменьшить количество обнаруженных ошибок. Мы добавили дополнительные ресурсы для ручного контроля качества, мы посвятили инженера на полную ставку исправлению ошибок и даже остановили всю работу над функциями, чтобы участвовать в периодических спринтах ошибок в рамках всей команды. В конце концов, однако, ни одна из этих стратегий, похоже, не приводила нас к тому месту, где снижалось общее количество ошибок. Становилось трудно уверенно строить поверх существующего кода.

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

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

Отправляйтесь в увлекательное приключение с уверенностью

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

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

Итак, о каком коде мы говорим? В Wayfair наш интерфейс состоит из React и простого JavaScript, в то время как наш внутренний серверный код прекрасно существует на PHP. Мы столкнулись с большинством наших ошибок в JavaScript, и более 70% работы, которую выполняли команды Idea Boards и Room Planner, приходилось на нашу кодовую базу внешнего интерфейса.

Jasmine, Enzyme и совсем недавно Jest были тремя тестовыми библиотеками JavaScript, которые мы выбрали для написания тестов для разработчиков; они предоставляют простые и интуитивно понятные API для разработчиков. Они также позволяют нам писать тесты на том же языке программирования, что и тестируемый код.

Для начала мы оценили количество обращений к багам за последние 3–4 спринта и определили наиболее критические места в нашем приложении, в которых мы столкнулись с серьезными ошибками. Затем мы написали специальные билеты, чтобы добавить тесты разработчика для этого поведения. Мы также позволили сферу применения этих билетов включать, при необходимости, легкий рефакторинг кодовой базы функций при разработке тестов для нее.

Тесты, которые мы начали писать, имели две разные формы: тесты самого маленького, самого низкого уровня охватывали один компонент, функцию JavaScript или другой отдельный файл кода, чтобы утверждать, что он ведет себя так, как был написан. Вы также можете знать их как модульные тесты. Для второго типа мы использовали библиотеку тестирования Enzyme, чтобы написать тесты пользовательского уровня, которые будут включать многие уровни нашего кода JavaScript. Эти тесты будут имитировать уровень API / данных и утверждать, что когда пользователь заполняет определенную форму или нажимает определенную кнопку, он увидит правильный ответ в HTML.

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

Последовательность порождает успех ... и хорошие привычки

Что произошло дальше? Перенесемся в март 2018 года, и теперь у нас есть все инженеры Idea Boards и Room Planner, которые пишут тесты в течение нескольких месяцев. Нормы нашей команды развились до такой степени, что каждая функция включает написание (или обновление) наших автоматических тестов. Ниже вы можете увидеть картину того, как наш список ошибок изменился с течением времени с тех пор, как мы начали писать и поддерживать набор автоматических тестов для разработчиков.

Хотя наша команда также приложила усилия, чтобы вкладывать время и усилия в исправление ошибок, как только мы их обнаруживаем, захватывающая тенденция заключается в том, что скорость обнаружения (или создания) новых ошибок за шесть месяцев снизилась. Это доказательство того, что время инженеров, которое мы вкладываем в написание тестов, окупается. В течение этого времени мы ни в коем случае не прекращали создавать и поставлять новые функции. Пока я пишу, мы только что запустили две большие новые функции (обе покрываются тестами разработчиков) для сохранения элементов и планирования комнаты, которые кардинально изменят то, как клиенты используют эти инструменты. В более анекдотичной форме обратной связи наши инженеры по планированию комнат и доскам идей считают, что тесты, которые у нас теперь есть, помогают предотвратить появление других ошибок, которые они бы пропустили, а наши инженеры по контролю качества отмечают, как трудно было «сломать наши вещи». ».

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

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