Our library can run both inside and outisde the InvokeStore async context. As such, I have suites of concurrency tests to verify theconcurrency behiours I expect to see. After the change in v0.2.x to change the instantiation logic, ie., the introduction of getInstanceAsync this has made testing much more difficult.
This is because the new _testing field is only added if the AWS_LAMBDA_BENCHMARK_MODE is set to 1 at the very first time the module is imported. This means that if InvokeStore is imported at the top level anywhere before your test, i.e., in application code, then the _testing.reset function will not be there. Using vi.strubEnv in a before block will not work because it is too late, the module has long been imported before then.
I propose that this reset function should always be available without the need for AWS_LAMBDA_BENCHMARK_MODE to allow for ease of testing for codebases that need to support both environments where InvokeStore needs to be use to manage async contexts and where it does not
Our library can run both inside and outisde the InvokeStore async context. As such, I have suites of concurrency tests to verify theconcurrency behiours I expect to see. After the change in
v0.2.xto change the instantiation logic, ie., the introduction ofgetInstanceAsyncthis has made testing much more difficult.This is because the new
_testingfield is only added if theAWS_LAMBDA_BENCHMARK_MODEis set to 1 at the very first time the module is imported. This means that ifInvokeStoreis imported at the top level anywhere before your test, i.e., in application code, then the_testing.resetfunction will not be there. Usingvi.strubEnvin abeforeblock will not work because it is too late, the module has long been imported before then.I propose that this
resetfunction should always be available without the need forAWS_LAMBDA_BENCHMARK_MODEto allow for ease of testing for codebases that need to support both environments whereInvokeStoreneeds to be use to manage async contexts and where it does not