add a testing harness to ease testing of lambdas #59
Conversation
motivation: make testing lambda easy changes: * add a AWSLambdaTesting module * add helper methods for testing different types of Lambda handlers / closures
tomerd
force-pushed
the
feature/testing-harness
branch
from
76815fb to
6b8acb3
Compare
There was a problem hiding this comment.
I really like this approach. A couple of notes though:
Implemented my notes:
https://github.com/swift-server/swift-aws-lambda-runtime/pull/60/files
| // testing helper | ||
| .target(name: "AWSLambdaTesting", dependencies: [ | ||
| "AWSLambdaRuntime", | ||
| .product(name: "NIOHTTP1", package: "swift-nio"), |
There was a problem hiding this comment.
From what I can see the dependency is NIO and not NIOHTTP1.
| import NIO | ||
|
|
||
| extension Lambda { | ||
| public static func test(_ closure: @escaping StringLambdaClosure, |
There was a problem hiding this comment.
I'm very excited about this API design. 😍
|
|
||
| public static func test<In, Out, Handler: EventLoopLambdaHandler>(_ handler: Handler, | ||
| with payload: In, | ||
| _ body: @escaping (Result<Out, Error>) -> Void) where Handler.In == In, Handler.Out == Out { |
There was a problem hiding this comment.
Do we want to work with completion blocks here?
I would be in favor of a sync api, which returns an Out and throws:
public static func test<In, Out, Handler: EventLoopLambdaHandler>(
_ handler: Handler,
with payload: In) throws
-> Out where Handler.In == In, Handler.Out == Out Going for such a sync approach would safe developers from using XCTestExpectation, which should make testing code much nicer.
This change should trickle down to all other methods of course.
| with payload: In, | ||
| _ body: @escaping (Result<Out, Error>) -> Void) where Handler.In == In, Handler.Out == Out { | ||
| let logger = Logger(label: "test") | ||
| let eventLoopGroup = MultiThreadedEventLoopGroup(numberOfThreads: 1) |
There was a problem hiding this comment.
Going for a sync approach, will allow us to defer { eventLoopGroup.syncShutdown() }
| invokedFunctionArn: "arn:aws:lambda:us-west-1:\(DispatchTime.now().uptimeNanoseconds):function:custom-runtime", | ||
| deadline: .now() + 5, | ||
| logger: logger, | ||
| eventLoop: eventLoopGroup.next()) |
There was a problem hiding this comment.
Do we maybe want to create a
struct TestConfig {
let requestId: String
let traceId: String
let invokedFunctionArn: String
let timeout: Double
}that can be optionally injected into the Lambda.test method, which could allow developers to test Timeout handlers and so on.
| deadline: .now() + 5, | ||
| logger: logger, | ||
| eventLoop: eventLoopGroup.next()) | ||
| handler.handle(context: context, payload: payload).whenComplete { result in |
There was a problem hiding this comment.
Should we execute this on the eventLoop as it would happen in the real environment?
| typealias Out = Void | ||
|
|
||
| func handle(context: Lambda.Context, payload: In, callback: @escaping (Result<Out, Error>) -> Void) { | ||
| callback(.failure(MyError())) |
There was a problem hiding this comment.
I'm afraid all those test cases work only because the callback is immediately called.
|
closing in favor of #60 |
motivation: make testing lambda easy
changes: