2

У меня есть nodejs Приложение на основе expressjs, которое я тестирую с использованием gruntjs в качестве задачи бегуна и mochajs в качестве тестового фреймворка. Таким образом, я написал компонентные, интеграционные и модульные тесты, которые выполняются через grunt test или непосредственно через mocha test/component/v1/apiX локально, когда я разрабатываю и тестирую VM во время развертывания как часть процесса CI.Тесты Mocha в безсерверном AWS Lambda Express App

Теперь, когда речь идет о переходе это приложение к AWS Lambda ака going serverless следующие вопросы приходят на ум в отношении моего тестирования и CI процесса (обратите внимание, что я буду использовать aws-serverless-express и, таким образом, не придется писать лямбда-функции явно):

1) Как реализовать тесты компонента/e2e, которые выполняются через HTTP-запросы api?

2) Как реализовать интеграцию & единичные тесты, которые загружают только &, тестируют часть приложения?

3) Как интегрировать оба с новым потоком CI, который отклоняет развертывание, если какой-либо из тестов завершился неудачей?

Я рассматриваю вопрос 1) в основном решается: существует множество подходов к проверке AWS Lambdas снаружи. Вы можете выполнить lamba-to-лямбда-тестирование, вызвав вашу лямбда-тест непосредственно из тестовой лямбда, или вы можете вызвать лямбда-тест через AWS API-шлюз, используя HTTP из test-lambda, как описано here. Вы также можете использовать serverless-mocha-plugin для локального тестирования лямбда (при использовании serverless).

Это 2) где это становится интересным: как только ваша лямбда развернута, это черный ящик. Вы не можете выполнить что-либо, что явно не объявлено как лямбда-интерфейс. Как сохранить или повторно реализовать существующий модуль мокко &?

То же самое для 3): как вы делаете свой CI запустили все тесты развертывания и отклонения развертывания, если они не сработают?

Здесь мой собственный подход: я сделал бы приложение для узла без сервера без использования только в среде TEST. Просто позвольте ему работать как HTTP-сервис классического узла, сделав все безсерверные изменения условными в зависимости от среды. Поскольку требуется несколько изменений, это должно быть возможным и поддерживаемым. Теперь я могу запускать тесты, как обычно, локально и при развертывании с хрюканьем и моккой. Тогда у меня все еще может быть последнее тестирование лямбда-лямбда, если я хочу быть уверенным, что версия без сервера работает.

+1

Я использовал [lambCI] (https://medium.com/@hichaelmart/lambci-4c3e29d6599b#.r08k0vlnh) раньше для такого рода вещей. Я думаю, что чтение этой статьи поможет вам понять все идеи автора (очень близкие к вашему) и пределы, которые он нашел с ним - то есть лямбда 300 секунд жизненного цикла, без поддержки докеров и т. Д. – MarcoL

+0

спасибо, я посмотрю ! –

ответ

1

Ваш подход звучит хорошо. И как для 3 вы можете просто ваш CI работает локальные тесты, развернуть на «DEV» или «тест» окружающей среды и запустить lambdaTests

grunt # run grunt commands including local mocha tests 
serverless deploy --stage test # deploy to test environment (serverless#1.0 syntax) 
grunt lambdaTest 

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

+0

благодарит за отзыв, звучит для меня тоже –