Я категорически не согласен с ответом @ ttulka, поэтому решил добавить и свой.
Учитывая, что вы получили событие в своей функции Lambda, весьма вероятно, что вы обработаете событие и затем вызовете какой-либо другой сервис. Это может быть вызов S3, DynamoDB, SQS, SNS, Kinesis ... Вы называете это. Что тут утверждать?
Правильные аргументы!
Рассмотрим следующее событие:
{
"data": "some-data",
"user": "some-user",
"additionalInfo": "additionalInfo"
}
Теперь представьте, что вы хотите вызвать documentClient.put
и хотите убедиться, что передаваемые вами аргументы верны. Скажем также, что вы НЕ хотите, чтобы атрибут additionalInfo
был сохранен, поэтому где-то в вашем коде у вас будет это, чтобы избавиться от этого атрибута
delete event.additionalInfo
право
Теперь вы можете создать модульный тест для утверждения , что правильные аргументы были переданы в documentClient.put
, что означает, что конечный объект должен выглядеть следующим образом:
{
"data": "some-data",
"user": "some-user"
}
Ваш тест должен утверждать, что documentClient.put
был вызван с JSON, который по глубине равен JSON выше.
Если вы или любой другой разработчик по какой-либо причине удалите строку delete event.additionalInfo
, тесты начнут проваливаться.
И это очень сильно! Если вы убедитесь, что ваш код работает так, как вы ожидаете, вам вообще не нужно беспокоиться о создании интеграционных тестов.
Теперь, если Lambda-потребитель SQS ожидает, что в теле сообщения будет какое-то поле, производитель Lambda всегда должен позаботиться об этом, чтобы убедиться, что в очереди сохраняются правильные аргументы. Я думаю, что теперь вы поняли идею, верно?
Я всегда говорю своим коллегам, что если мы сможем создать правильных модульных тестов, мы должны быть хороши в 95% случаев, оставляя интеграционные тесты неактивными. Конечно, лучше иметь и то и другое, но, учитывая количество времени, затрачиваемое на создание интеграционных тестов, таких как настройка сред, учетных данных, иногда даже разных учетных записей, не стоит. Но это только мое мнение. И вы, и @ttulka более чем согласны.
Теперь вернемся к вашему вопросу:
Вы можете использовать Sinon для проверки и утверждения аргументов в ваших лямбда-функциях. Если вам нужно смоделировать сторонний сервис (например, DynamoDB, SQS и т. Д.), Вы можете создать фиктивный объект и заменить его в тестируемом файле, используя Rewire . Обычно это та дорога, по которой я езжу, и до сих пор она была великолепной.