Запись, опубликованная 15 марта 2016 г. в моем старом блоге.

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

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

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

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

Идея непрерывного

Непрерывное развертывание, доставка и интеграция — это три понятия, тесно связанные друг с другом.

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

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

Непрерывное развертывание — это развертывание или выпуск кода в производство, как только он будет готов. Тестирование выполняется до слияния с основной веткой и выполняется в средах, подобных производственной.

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

Автоматизированные тесты

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

  • Модульные тесты
  • Интеграционные тесты
  • Сквозные тесты

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

Интеграционные тесты должны проверять поведение отдельных модулей (которые уже прошли модульное тестирование), интегрированных вместе, как правило, с использованием подхода «сверху вниз» или «снизу вверх».

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

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

Тестируемый JavaScript

Существует множество инструментов и фреймворков для написания тестов для ваших JS-приложений. Я лично использую Mocha для модульных и интеграционных тестов. Для end-to-end тестов использую Supertest для API и NightWatch или Dalek для фронтенда. Я использую Чай для утверждений.

Если вам не нравится мокко, обратите внимание на Tap или Jasmine. И если вы разработчик AngularJS, вам, вероятно, будет интересен Protractor.

Я также видел, как некоторые люди использовали Хиппи вместо Супертеста. Честно говоря, я никогда не пробовал его раньше, но, читая документацию, он тоже кажется хорошим минималистичным пакетом.

От источника до производства в моем реальном мире

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

В Impero, компании, где я работаю главным инженером-программистом, мы используем git для управления исходным кодом с ветками функций и веткой master/main/production. Наша инфраструктура построена на Deis, PaaS с открытым исходным кодом, который упрощает развертывание и управление приложениями на ваших собственных экземплярах (мы на 100% используем Amazon AWS).

В частности, мы используем GitHub или Gitlab для контрольной версии, Circle CI или Strider в качестве сервера непрерывной интеграции, в зависимости от того, являются приложения открытым исходным кодом или нет.

Давайте посмотрим, как это работает. У нас есть ветка для каждой функции/ошибки, над которой мы работаем. Как только код в этой ветке готов к запуску, разработчик запускает модульные тесты локально, и если они пройдены, код фиксируется в конкретной функциональной ветке и помещается в централизованное репозиторий git. Здесь сервер непрерывной интеграции получает изменение, выполняет тесты, описанные выше, и в случае успеха объединяет новый код с основной ветвью, создает образ Docker, передает его в реестр и развертывает в промежуточной среде, генерируя четко определенный релиз Deis. На этом этапе у нас есть возможность просмотреть или нет изменение и провести ручное тестирование качества. Если все в порядке, мы можем просто развернуть созданный нами образ докера в рабочей среде.

Откаты

Может случиться так, что что-то пойдет не так, и если это произойдет, у нас есть сценарий отката, который просто заставит Деиса повторно развернуть предыдущий рабочий выпуск.