Just curious, hopefully I don't start a war here :...
# help
r
Just curious, hopefully I don't start a war here ๐Ÿ™‚ Do folks test APIs by deploying to a test stage and running tests that hit those URLs on AWS through APIGateway or do you all like to mock AWS APIGateway events and call your functions directly?
s
I think there are no wrong answers here, only tradeoffs. I like the idea of a non-mocked end to end test when possible, but appreciate there are times to test isolated pieces of the architecture
r
Alright Seth is Switzerland, who else we got ๐Ÿ™‚
s
I personally prefer not to mock
r
I am with ya though, I dont think there is a wrong answer ๐Ÿ™‚ I like the idea of calling the API so then we test AWS api gateway and the whole shabang as it will really happen. However calling locally gives you the benefit of the call stack and more handy info when trying to use tests to fix and repeat. An API respose will probably be like status 400 and some generic user facing message. Also cant really do any code coverage #'s with the full API, as most of your code being called is remote.
s
I can't remember where I heard this (Paul Swail?), but liked the advice to mock what you cannot control (e.g party API s)
r
Yeah that seems like a pretty safe rule.
s
Love to hear what others are doing here
d
About 90% unit (mocked), 8% integration (still not API Gateway, usually the framework operating beneath it), 2% E2E (API Gateway). This is in terms of # of tests.
I consider the E2E completely optional, and generally just do so from the frontend.
r
For your Lambdas that are triggered by API Gateway are they all e2e or do they mix into the others?
d
Not sure entirely what you mean, but generally I dont involve AWS infra unless its an E2E test.
Not even lambda.
Mike Cohn had a solid, easy to reference idea on the topic: The Practical Test Pyramid (martinfowler.com)
r
Whatever your handler function is for an API endpoint through API Gateway. do you just call it with a mock event, or do you fetch it remotely to test it.
d
I recommend either mocking the event, or testing one level deeper (like say, a function called directly inside the handler). The latter is useful if you want to avoid authZ and the like.
I recommend just not ending up with a test ice cream cone (inverted pyramid). Nightmare to maintain. Any kind of unit test is more the merrier though.
r
Gotcha, how far do you try to take mocking? Like for example would you mock dynamo locally? or let that live live on AWS?
d
Recommend Dynalite or DynamoLocal, depending on whether you are using transactions.
In memory speeds things along quite a bit.
Both are available as presets for Jest.
But I also have models that stand in front of any persistence layer, and I just mock those in the API.
Optional, obviously, but I like to abstract which kind of DB anything is from business logic.
The model tests hit Dynamo directly.
r
Gotcha. so Derek is into the mock strategy. that's cool
d
About 90% into it ๐Ÿ˜‰ ๐Ÿ‘†
r
fair enough ๐Ÿ™‚
d
My opinion: the smaller the scope, the easier to maintain, so I mock anything that isnt the โ€œmain ideaโ€ of what I am testing.
m
Do you mean automated testing or while in the fury of hacking? I usually mock the events for unit tests, but while in active dev, I want as much cloud in the mix as possible. I hear there's this tool SST that helps with that (but also you have CDK hotswap, SAM accelerate, etc - can't see why I wouldn't do this).