You could write end to end tests, but it means a deployment after each change and then checking the logs to see what failed. Even if you use iac (terraform/pulumi), the deployment will take seconds or a minute or two - not exact rapid test feedback.

What I have been doing is to set up a hook which is called from the lambda handler, which can also be called locally. Within the test, I then assume the role that runs the lambda and then test the hook.

This mechanism allows to me easily test that the permissions are set up correctly and that details are in place for the code to work.

For the full end to end test, I then have a simple smoke test or two.

The code samples are in golang(only because it happens to be my current language of choice), but the idea should be equally applicable in other languages.

Assuming The Role

the cfg is then passed into the New method for the resource you are interested in. e.g.:

Working Example

You can find a full, working example test in my github repo under post/2023/11/autolambdatest

NOTE: It WILL automatically try and deploy a role and a ssm parameter, and it will delete it after the test.

The BeforeSuite will deploy the minimum configuration to be able to run the test, and the AfterSuite will destroy the same stack.

You will likely need to log into pulumi to get this test to work.

If you run into permissions issue for AssumeRole, read on.

AssumeRole Permissions

For this to work, the user running the tests need to have permissions to AssumeRole.

There are two steps to this. The first part is to allow "anyone" to AssumeRole the relevant role:

You can add it to your ~/.bazelrc (it needs the path to be absolute)

From our integration tests, we run pulumi stack output (or in some cases pulumi up) through the automation API before we run the tests so that we can

• Confirm that the stack is up
• Get the relevant parameters (actual names of lambdas / dynamo db tables etc.)

However, since we use bazel for our tests, we ran into a small problem in that Bazel (rightly) prevents the tests from writing to anything outside the sandbox. This restrictions results in this error

Unit tests are designed to run as fast as possible, so any slower processes like databases are mocked out. While super helpful and powerful in terms of providing confidence in the software, it should be only one part of the testing strategy.

Integration tests, as is implied runs tests of the different part of the software integrated together. Technically speaking, you can still mock out the database and other slower layers to keep it running quickly. However, there is value in including a database or other slower services in the process to test as them in an automated fashion.

What this does mean though, is that you want to be able to run only the unit tests or run the integration tests as well. You might also want to have smoke tests, which are run on your live production environment.

How

You could define a separate target in your BUILD file with the unit tests and let gazelle automatically build your default test target with all the tests. I found this frustrating to use as I had to keep tweaking the dependencies manually whenever anything changed (which happened often)

Tagging

The easiest way to achieve this for golang and bazel is to tag your source code files. You can do this by adding the following to the top of your integration test files

something_integration_test.go

You can pick any tag name you want instead of integration_test like integration, smoke_test etc.

IDE Support

You will likely need to add this source file into the IDEs build constraints to get the IDE to treat it as a source file. In IntelliJ (IDEA/Goland), you will be warned of this

If you click Edit settings, you can add the tag in

When running gazelle, you want to include the files with these tags

Gazelle

If you have multiple tags, you can separate them with commas. This command will generate a test target with all of the source files and its dependencies

Bazel Integration on test

To run only the unit tests, you test as normal:

To run the integration tests as well, include that tag

Run only Unit Tests

This setup will currently not allow you to run ONLY the integration tests. To be able to do that you'll need to add a unit_test tag to the unit test files so that you can exclude them.

You can then run only the unit tests with

Only the integration tests

Or both:

Simpler gazelle command

You can enable the tags by default in the BUILD file so that you don't have to pass the tags into gazelle each time.

BUILD

You can then just run bazel run //:gazelle which will run with these tags enabled.

Sample Source

You can find sample source code demonstrating this in my github repo, under post/2023/11/separatetests

Simple? NO! The main problem was the management of the data set. I had set up, in the past fairly interesting classes to test the functionality using reflection, and injecting the data from the classes themselves through the data provider mechanism of TestNG. However, this was error prone and clunky at best. It also made dependency management of data quite cumbersome.

With a view to resolving this, I also looked at DbUnit, unitils and Ejb3Unit. They all did some things that I liked but lacked some functionality that was important.

This led me to write a simple testing infrastructure. The goal was straightforward.

• I need to be able to define data in a CSV (actually it was seperated by the pipe character |, so PSV) based on entities.
• The framework should automatically persist the data (and fail on errors)
• It should test that it can load all that data back
• It should run as many automated tests on the DOM as possible.

The framework uses the CSV files to read the data for each of the classes (using the excellent SuperCsv library). It needs an Id field for internal reference. As long as the id’s match within the CSV files for the relationships, it will be persisted correctly into the database even when the persisted id’s are different.

For example, I could have a Contact.csv with 5 records (ids 1 through 5) and a Company.csv with 3 records (ids 1 through 3).

The Contact.csv records can map to the id specified in the Company.csv file and when the records get persisted, they will be associated correctly, even if the id’s in the database end up being different.

The framework also looks for the CSV file which has the same name as the class within the location defined within the configuration file. This means that as long as the filename matches the class name, the data loading is automatic.

For simple classes, the Test case is as simple as: