Почти на каждом собеседовании с разработчиком программного обеспечения, которое я видел, и интервьюер, и собеседник говорили ужасную ложь: им нравится TDD (разработка через тестирование), и они никогда не начинают проект без него. Сокращение до нескольких недель спустя, и они потеют, чтобы увеличить процент покрытия в своем коде, чтобы пройти хотя бы отметку в 50%.

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

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

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

Эти тесты необходимы каждому проекту, но когда вы работаете с чем-то столь же изменчивым и новым, как AWS Lambda, автоматические тесты становятся вашими уведомлениями, которые сообщают вам, что что-то изменилось, даже если вы не касались своего кода.

Самый дешевый способ разработки: TDD

Serverless Framework предлагает команду invoke, которая позволяет запускать ваши лямбда-функции, позволяя передавать входные данные функции rcprvyd. Единственным условием для этого является то, что вы должны развернуть свои функции в AWS, прежде чем пытаться их вызвать.

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

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

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

Поскольку мы используем Node.js для наших сервисов, давайте воспользуемся существующими инструментами Node.

Мокко и Вавилон

В нашем случае подойдет любой тестовый фреймворк для Node.js. Я выбираю Mocha, потому что это просто, и я к нему привык; но вы можете использовать любой другой инструмент, который вам удобен.

Давайте начнем новый проект с Serverless Framework, настроим Mocha для создания наших тестов и Babel, чтобы использовать такие функции ES6, как Class.

В прошлом году AWS начала поддерживать Node.js 4.3.2, который представил ES6. Однако нам нужен Babel for Mocha для переноса кода ES6 для наших тестов.

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

В бессерверном режиме будут созданы ожидаемые файлы handler.js и serverless.yml. Давайте установим Mocha и Babel, чтобы приступить к созданию тестов.

Внутри папки taco-gallery запустите проект Node.js и установите зависимости, выполнив следующие команды:

npm init

npm install - сохранить babel babel-core babel-preset-es2015 mocha chai

npm install -g mocha

Также не забудьте поместить файл .babelrc в корень нашего проекта. Это гарантирует, что когда мы запустим наши тесты, Babel перенесет наш код на ES2015 (ES6).

Файл handler.js по умолчанию имеет только одну функцию, hello. Тестирование этой функции тривиально, но это хорошее начало.

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

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

Сотрудники Serverless Framework понимают это ограничение и написали руководство по модульному тестированию. Давайте последуем их примеру и отделим нашу бизнес-логику от бессерверных функций:

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

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

В нашем следующем посте мы представим базу данных DynamoDB и добавим больше бизнес-логики.