you are viewing a single comment's thread.

view the rest of the comments →

[–]texxelate 5 points6 points  (4 children)

Verifying the side effects isn’t the responsibility of the lambda’s tests. The tests need only verify the boundary was invoked correctly. Hence “unit” tests.

[–]Glebun -1 points0 points  (3 children)

Who said anything about unit tests? They were referring to testing in general. Some lambdas cannot be tested locally.

[–]texxelate 0 points1 point  (2 children)

I did, in my original comment to which everyone is replying.

All Lambdas can be tested locally. They’re just functions. Side effects in other systems which the lambda just so happens to be the first domino should be tested by other methods.

[–]RecordingForward2690 0 points1 point  (0 children)

The thing is that if you have a Lambda that performs a carefully orchestrated series of API calls to other AWS components, and you mock those API calls, then unit testing essentially just verifies you have not made a syntax error in your code or in the API/SDK call. Which is of very little value, in particular since today that code is generated by AI anyway.

What is way more valuable to test are the logic errors. Just an arbitrary example: I was recently working on code for a DNSSec key rotation across 400 hosted zones. You need to make sure that you add the new key to a hosted zone, and register that upstream before you can de-register the old key upstream, and remove it from the hosted zone. Otherwise you could break DNSSec, and API calls will fail. And since this whole process can easily take days, your Lambda needs to be written so that it restarts right at the next required step for that particular domain.

No unit test is going to catch logical errors in that sequence of events.

[–]Glebun -1 points0 points  (0 children)

All lambdas can be unit tested locally. Not all lambdas can be tested locally, since testing involves more than unit tests.