[Testing] Test Framework Generalization

[erikschlegel]

A good user story should be (I-N-V-E-S-T principle)

• Independent (from other user stories, allowing to realize them in any order);
• Negotiable (omit details that would freeze the story);
• Valuable (implementation delivers an increment of functionality, observable by and useful to users);
• Estimable (developers should be able to estimate its size relative to other stories);
• Sizable (implementation fits in one iteration – if it needs many to complete, it is an EPIC);
• Testable (user must be able to check the conditions of satisfaction).

Description

*As a developer, I'd like to leverage an testing framework in order to reuse automated test stages across terraform templates. Some of these stages comprise of terraform plan inspection, E2E app service connectivity assertions, Terraform template linting, etc.

Acceptance Criteria

Reference: [Done-Done Checklist] (https://github.com/Microsoft/code-with-engineering-playbook/blob/master/Engineering/BestPractices/DoneDone.md)

• Testing framework should still live in this repository, but should be designed in a way that is shareable between multiple repos/projects
• Define and implement common patterns for unit testing
• Define but not necessarily implement common patterns for integration testing
• Define and implement consistent lint checks for *.go files. If any *.go files do not pass linting, the build should fail
• Define and implement consistent lint checks for *.tf files. If any *.tf files do not pass linting, the build should fail

Tasks

• Fail builds if *.go files do not pass lint checks
• Fail builds if *.tf files do not pass lint checks
• Define consistent testing patterns for unit testing TF modules/templates
• Implement generic testing harness that simplifies writing unit tests for TF modules/templates
• Define consistent testing patterns for integration testing TF modules/templates
• Write story to implement generic testing harness that simplifies writing integration tests for TF modules/templates

[nmiodice]

Story for integ tests: #109

[nmiodice]

Story for moving harness to its own repo: #110

[nmiodice]

Pattern for integration test implementation

// Something like this can be used to hold a reference to:
//    - Go Test
//    - Terraform Options
//    - List of user-defined functions that can be run to validate the deployment
//    - etc...
type IntegrationTestFixture struct {
	GoTest                *testing.T         // Go test harness
	TfOptions             *terraform.Options // Terraform options
        ...
}

// Something like this can be used to manage the terraform and test lifecycle
func RunIntegrationTests(fixture *IntegrationTestFixture ) {
}

Clients can use this using code similar to:

func TestFoo(t *testing.T) {
	test_fixture := infratests.IntegrationTestFixture{
		GoTest:                t,
		TfOptions:             buildTerraformOptions(),
                ...
	}

	infratests.RunIntegrationTests(&test_fixture)
}