Implement Terraform test functionality to all modules

[helenakallekleiv]

Module Name

All

Description

Implement Terraform test functionality to all modules.

• ACR
• App Config
• App Insights
• Automation
• Databricks
• Event Grid
• Function App
• Grafana
• Identity
• Key Vault
• Log Analytics
• NAT
• Network
• Postgres
• Public IP
• Service Bus
• SQL
• Storage
• Synapse
• VM
• Web App

Example Terraform Configuration

.
└───tests
    ├───unit.tftest.hcl
    └───setup
        ├───main.tf
        └───outputs.tf

[helenakallekleiv]

Also update the Testing section in the docs.

• https://equinor.github.io/terraform-baseline/best-practices/testing/#testing

[helenakallekleiv]

@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.:

• Check if firewall is turned on
• Check public network access
• Check tier
• Check kind
• Check enabled diagnostic setting

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]

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]

Using sql module as example.

If grouped by "Resource type":

• server.tftest.hcl
• database.tftest.hcl

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":

• admin.tftest.hcl
  • Azure AD authentication enabled/disabled
  • TODO
• identity.tftest.hcl
  • Correct identity type?
  • Correct identity id format?
• firewall.tftest.hcl
  • Is firewall enbaled?
  • Correct ip address format?
  • Duplicate ip addresses?
• policy.tftest.hcl
  • Security alert
  • vuln. assessment
  • extended audit policy
• logs.tftest.hcl
  • TODO
• rbac.tftest.hcl <-- This could perhaps go under identity.tftest.hcl?
  • TODO
• retention.tftest.hcl <-- Specifically database submodule
  • TODO