search

equinor / terraform-baseline

Best practices for creating reusable Terraform modules using the Azure provider
https://equinor.github.io/terraform-baseline/
MIT License
12 stars 5 forks source link

Implement Terraform test functionality to all modules #143

Open helenakallekleiv opened 7 months ago

helenakallekleiv commented 7 months ago

Module Name

All

Description

Implement Terraform test functionality to all modules.

Example Terraform Configuration

.
└───tests
    ├───unit.tftest.hcl
    └───setup
        ├───main.tf
        └───outputs.tf
helenakallekleiv commented 6 months ago

Also update the Testing section in the docs.

helenakallekleiv commented 5 months ago

@equinor/terraform-baseline-maintainers

I had an idea regarding the tests. As not all modules have specific tests but more general tests based on the Basic and/or Complete examples, I wondered if we could create a "general" set of test items to apply for all modules to speed this process up a bit.

The idea is to have a general set of things to test, maybe based on required variables, if there are no specific things.

E.g.:

Perhaps not the best explained idea, and most likely a generalized list of things to test will not work for all modules, but it gives a starting point and can additionally be added to the documentation as an overview of that we generally test for and how we test.

Any thoughts? 👀

hknutsen commented 5 months ago

A few different approaches to consider for grouping tests:

Group by Example file names Pros Cons
Testing method (unit, integration) unit.tftest.hcl, integration.tftest.hcl Easy to run a specific type of test, for example to run all unit tests just run the unit test file. Some modules create a large number of resources, which might lead to very large test files.
Resource type sql_server.tftest.hcl, sql_database.tftest.hcl, sql_firewall_rule.tftest.hcl Easy to run tests for the specific resource type relevant for your changes Some modules create resources with a large number of arguments and blocks, which might lead to very large test files for some resource types. Also, shouldn't the entire module be tested anyway, even though you only made changes to a few resources?
Feature azuread_administrator.tftest.hcl, identity.tftest.hcl, security_alert_policy.tftest.hcl, vulnerability_assessment.tftest.hcl Easy to test a specific feature of the module, for example configuration of managed identity Lots of test files.
helenakallekleiv commented 5 months ago

Using sql module as example.

If grouped by "Resource type":

Although we separate by main resource here, both would have the same type of tests, with the exception of the retention policy, which only applies to the database submodule. The grouping by "Feature", as shown below gives an overview of this.

If grouped by "Feature":