AWS Lambda 함수에 대한 의미 있는 테스트 작성 방법

잔혹한 사실

만약 무의미한 단원 테스트를 작성하려고 한다면, 이 테스트들은 오류를 폭로하지 않고 덮을 수 있으니, 이 연습을 완전히 건너뛰는 것이 가장 좋다.
됐어, 내가 말했어.
너의 시간은 귀중하다. 공허한 커버율을 실현하는 것보다 더 좋은 일에 쓸 수 있다.
코드의 유효한 테스트는 오랫동안 프로그래밍에서 도전적인 문제였다. 테스트를 작성할 때 AWS Lambda와 같은 새로운 도구는 개발자에게 최악의 결과를 가져다 준 것 같다.
나는 이것이 주로 로컬 렌즈 람다의 생산 환경이 비교적 어렵기 때문이라고 생각한다.그래서 일부 개발자들은 테스트를 완전히 포기했다.
나는 내가 직접 했기 때문에, 설령 생산 프로젝트에서라도.반대로 코드가 클라우드에 배치된 후에만 테스트는 집적 방식으로 진행된다.
이것은 매우 수동적이어서 장기적으로 보면 시간을 낭비할 것이다.내가 테스트에서 본 또 다른 방법의 결과는 다음과 같다.

이것은 공사팀이 테스트 범위의 요구를 가지고 있지만 책임감이 부족한 뚜렷한 징조이다.그리고 상술한 것이 허용되지 않는다는 것을 설명할 필요가 없습니다

그럼, 우리는sadtest_lambda_함수를 어떻게 변환합니까?위의py파일은 무슨 의미가 있습니까

Lambda 코드를 테스트하기 전에 몇 가지 장애가 있습니다.우리는 하나하나 이 문제들을 소개하고, 어떻게 그것들을 가장 잘 처리하는지 확정할 것이다.처리가 완료되면 Lambda를 마음대로 테스트할 수 있습니다

주의: 명확하게 보기 위해서 저는 본문에 작은 코드 부분을 포함할 것입니다.그러나 마지막에는 완전한 작업 코드 예시가 참고할 수 있습니다

장애 #1: 람다 트리거 이벤트

모든 Lambda 함수는 미리 정의된 트리거에 응답하기 위해 호출됩니다. 이 트리거는 특정한 event 데이터를 기본 lambda_handler() 방법으로 전달합니다.Lambda 함수를 유효하게 테스트하는 첫 번째 작업은 실제 입력 이벤트를 만들어 테스트하는 것입니다

이 이벤트의 형식은 트리거의 유형에 따라 다릅니다.본문을 작성할 때까지 16개의 다른 AWS 서비스가 Lambda의 호출 트리거로 사용할 수 있습니다

다음은 코드 세션입니다. 제가 가장 자주 사용하는 몇 가지 입력 예시를 포함합니다.

예시 입력 이벤트의 전체 목록은 AWS documentation 에서 찾을 수 있습니다.또는 배치 후 lambda_ 프로세서 코드에서 이벤트 변수를 인쇄하고 CloudWatch 로그에서 부하를 볼 수 있습니다:

일단 이 예가 생기면 테스트 파일에 하드코딩만 하면 위의 그림에서 보듯이 우리는 아주 좋은 시작을 할 수 있습니다

Hurdle #2: AWS Service Interactions

Lambda 함수는 다른 AWS 서비스와 거의 상호작용을 피할 수 없습니다.DynamoDB 테이블에 데이터를 쓰고 있을 수 있습니다.SNS 주제에 메시지를 올리거나또는 간단하게 CloudWatch에 지표를 보냅니다.또는 이 세 가지의 결합

테스트를 할 때 데이터를 보내거나 생산에 사용되는 실제 AWS 자원을 변경하는 것은 좋은 생각이 아니다.이 문제를 해결하기 위한 방법 중 하나는 단독 테스트 자원을 설치하고 잠시 후에 철거하는 것이다

단, 더욱 간결한 방법은 AWS 서비스와의 상호작용을 모의하는 것이다.이것은 흔히 볼 수 있는 문제이기 때문에, 이 특정한 문제를 해결하기 위해 가방을 개발했다.더 좋은 것은 그것이 매우 우아한 방식으로 이 점을 해냈다는 것이다

의 이름은 moto(mock&boto의portmanteau)로 그 우아함은 두 가지 주요 특징에서 비롯된다.

테스트에서 boto 클라이언트를 자동으로 수정하고 시뮬레이션합니다.
위조 AWS 리소스의 상태를 유지합니다.

이게 뭘 닮았어?모든 것이 필요한 것은 장식 마술과 작은 설정입니다

Lambda에서 S3에서 데이터를 읽는다고 가정합니다.우리는 S3에서 테스트 버킷을 만들고 채울 필요가 없고, moto를 사용하여 가짜 S3 버킷을 만들 수 있습니다. 그 외관과 행위는 실제 S3 버킷과 완전히 같고, 실제 AWS를 접촉할 필요가 없습니다

가장 좋은 부분은 우리가 표준적인 boto3 문법을 사용하여 이 점을 실현할 수 있다는 것이다. 예를 들어 아래에서 create_bucket와put_object 방법을 호출할 때의 예시와 같다.

유사하게, 만약 우리가 데이터를 DynamoDB에 쓴다면, 우리는 먼저 가짜 Dynamo표를 만들어서 테스트를 설정할 수 있다.

이것은 약간의 신뢰가 필요하지만, 테스트를 통과하면 코드도 생산 환경에서 작업할 수 있다고 확신할 수 있습니다

Okay, but not everything is covered by moto…

예, moto는 모든 AWS API와 동일하지 않습니다.예를 들어 만약에 Lambda 함수가 AWS Glue와 상호작용을 한다면 moto는 당신을 꼼짝 못하게 할 수 있습니다. 왜냐하면 Glue 서비스는 5%

여기서 우리는 소매를 걷어올리고 스스로 조롱해야 한다monkeypatching.AWS 관련 호출이나 Lambda가 접촉할 수 있는 외부 서비스, 예를 들어 Slack에 메시지를 발표할 때 모두 그렇습니다

물론 이와 관련된 용어와 개념이 갈수록 밀집되어 있기 때문에 하나의 예시를 통해 해석하는 것이 가장 좋다.우리는 AWS Glue를 계속 사용하고, 다음 코드로 우리 계정의 Glue 파충류를 열거하기를 간절히 바란다고 말합니다:

session = boto3.session.Session()
glue_client = session.client("glue", region_name='us-east-1')
glue_client.list_crawlers()['CrawlerNames']
# {“CrawlerNames”: [“crawler1”, "crawler2",...]}

만약 우리가 걸출한 테스트의 성공이나 실패가 list_crawlers() 응답에 달려 있기를 원하지 않는다면, 우리는 다음과 같은 반환 값을 하드코딩할 수 있다.

pytest monkeypatch fixture의 setattr 방법을 이용하여 lambda_handler 의 접착 클라이언트 코드가 실행될 때 MockBotoSession 클래스의 하드 인코딩list_clusters에 동적 접근할 수 있도록 허용합니다

이 솔루션의 장점은 모든 boto 클라이언트를 위해 작업할 수 있는 충분한 유연성에 있다

Tidying Up with Fixtures

Lambda 테스트에서 이벤트 입력과 외부 의존 관계를 처리하는 방법을 소개했습니다.제가 공유하고 싶은 또 다른 기교는pytestfixtures를 사용하여 조직적인 테스트 파일을 유지하는 것입니다

지금까지 코드 예시는 test_lambda_handler 방법 자체에서 설정 코드를 직접 보여 주었다.그러나 더 좋은 모델은pytest 고정 장치로 단독 set_up 함수를 만드는 것입니다. 이 고정 장치는 그것을 사용해야 하는 모든 테스트 방법에 전달될 수 있습니다

마지막 코드 부분에 대해 @pytest.fixture 장식기를 사용하여 이fixture 구조의 예시를 보여주고 포함된 모든 내용을 결합시킵니다:

우리는 이미 문장의 시작 부분의 빈 테스트 파일에서 매우 긴 길을 걷지 않았습니까

알림으로 이 코드 테스트 Lambda 함수:

sqs 메시지 이벤트 촉발
Dynamo 테이블에 메시지 쓰기
사용할 수 있는 풀 파충류 열거

단, 이러한 정책을 사용하면 모든 이벤트 유형에서 촉발된 Lambda, 그리고 모든 AWS 서비스와 상호작용하는 Lambda를 테스트할 자신이 있습니다

Final Thoughts

만약에 Lambda 함수를 테스트하려고 노력하고 있다면, 본고는 당신에게 유용한 방식으로 테스트를 진행할 수 있도록 기교를 보여 줄 수 있기를 바랍니다

우리는 흔한 문제와 Lambda를 어떻게 테스트하지 말아야 하는지를 연구하는 데 많은 시간을 들였지만 본 주제의 상반되지만 같은 중요한 측면, 즉 무엇을 테스트해야 하는지, 그리고 Lambda 함수의 코드를 어떻게 구성하여 더욱 쉽게 실현할 수 있는지 토론할 기회가 없었다

당신의 편지를 받고 Lambda 함수를 어떻게 테스트하는지 토론하기를 기대합니다

Vamshi Rapolu가 본문에 제공한 영감과 피드백에 감사드립니다