Комментарии 17
слушайте, вот прям всё офигенно в статье.
я смотрю на лямбды с момента их появления, но пока так и не начал их использовать.
причина в следующем: без покрытия кода автоматическими тестами чувствую себя слепым.
причём обычно мы покрываем как юнит-тестами так и интеграционными: раскладывая всё по докерам.
а вот как быть с лямбдами и автотестами в CI я пока так и не понял.
Вы говорите что любите серверлесс, не расскажите как с автотестами решаете проблемы?
допустим на SQS найти докер можно
наверно на DB тоже можно
а на лямбды докеры уже появились?
с моками — это неинтересное тестирование. я же писал что мы используем интеграционные тесты тоже.
Меняем один сервис, а это как-то отразилось на других. Тесты других не прошли или тесты этого сервиса (ранее написанные) не прошли.
С замоканным внешним миром есть проблема — что моканный мир может отличаться от реального.
а с поднятой копией внешнего мира, полноценной копией — этих проблем нет
Боюсь тут нет универсального решения. Интеграционное e2e тестирование удобно использовать в CI на мелких проектах, где зависимости можно пересчитать по пальцам. Но когда количество сервисов начинает измеряться десятками (или десятками сотен как у нас), то мысль разворачивать весь мир разом ради проверки очередного инкремента в каком-то из винтиков становится довольно утопичной. Это не только про лямбды, а вообще. Мы ушли от запуска e2e на CI в сторону контрактного тестирования - сравнения схем и https://pact.io/. Подход предлагает несколько крутых идей, помогающих решать вопросы с актуальностью моков. e2e остается, но в значительно меньших объемах, больших масштабах, и этим занимаются QA.
Мы просто вываливаем в dev environment и запускаем интеграционные тесты. А юнит-тесты во время сборки прогоняем, так же как и SCA.
Кроме того есть вот такая интересная штука: github.com/aws/aws-lambda-runtime-interface-emulator
Вы говорите что любите серверлесс, не расскажите как с автотестами решаете проблемы?
допустим на SQS найти докер можно
наверно на DB тоже можно
а на лямбды докеры уже появились?
Посмотрите на AWS SAM. Он позволяет локально запускать лямбды с докером. Локально дебажить, юнитестить, деплоить в облако и т.д.
Интеграционные тесты можно запускать в облаке используя CodePipeline или GitHub actions.
Мой вам совет — НИКОГДА не используйте Cognito. Просто забудьте про него, как страшный сон.
Захотите использовать нормальный OAUTH 2.0 с поддержкой scope — добро пожаловать в ущербный Hosted UI, в котором вы поменять не можете ровным счетом ничего. Не хотите Hosted UI? окей, тогда всем пользователям будет выдаваться токен со scope=user.admin (условно), и пользователь с фронта с таким токеном может обратиться напрямую в API Cognito, и к примеру себя удалить. И запретить это невозможно никак (не используя ущербный Hosted UI).
Вы мне всё еще не верите, и думаете что Cognito — норм?
Зайдите на его страницу в раздел «Разработчики доверяют нам»
aws.amazon.com/ru/cognito, посмотрите эти проекты.
Вы там не то что Cognito не найдете, а вообще никакой рабочей авторизации и регистрации нет.
Как выглядит обычная 100%-но бессерверная архитектура в AWS Lambda