The question with integration testing is: What components are integrated?
In most cases we speak of different parts of a software, which are build together. With Infrastructure as Code you can see integration test as the integration with the cloud services.
So the integration test checks, whether your CDK Code really creates the defined resource. To support this, we use the CIT - CDK Infrastructure Testing framework/concept.
It computes the physical ID (2) logincomingobject* from the AWS Resource from a logical ID **(1)** e.g. *myhandler* defined in the CDK. With the physical ID you can use the GO SDK to read the Resource, because all “read” or “describe” calls need a AWS physical ID to reference Resources.
With that approach you can work with the names defined in the CDK code during test, that is easier because the physical IDs change with each deployment.
The check for the physical Lambda Resource is written in the file integration_test.go:
We have some new imports:
Import | purpose |
---|---|
“gotest.tools/assert” | better assertion framework |
“github.com/aws/aws-sdk-go-v2/aws” | values to pointers |
“github.com/megaproaktiv/cit/citlambda” | the cit module |
To control the test level we use environment variables:
if os.Getenv("I_TEST") != "yes" {
t.Skip("Skipping testing in non Integration environment")
}
The test itself is short:
16 gotFc, err := citlambda.GetFunctionConfiguration(aws.String("dsl"),aws.String("myHandler"))
17 assert.NilError(t, err, "GetFunctionConfiguration should return no error")
18
19 expectHandler := "main"
20 assert.Equal(t, expectHandler, *gotFc.Handler )
The name of the stack is defined in the main function:
dsl.NewDslStack(app, "dsl", &dsl.DslStackProps{
And the name of the function construct, which was defined in dsl.go :
myHandler := awslambda.NewFunction(stack, aws.String("myHandler"),
...
As we have tested and installed the infrastructure, now we go to the application (the Lambda function) in the next chapter.
See the full source on github.