refactor!: adding a type for rule input

[benpriestman]

Adding an object type for the rule input.
Also adding a suite of tests, based upon and extending the current examples.

Features:

• allows changes to be made with higher confidence;
• highlights some inconsistencies in the codebase (compare not_statements in different contexts);
• makes it easier for newcomers to learn how to use this module;
• allows IDEs to give useful hints and autocompletions;
• makes it possible for AIs to make reliable choices when coding around this module.

[uyggnodoow]

Hello @benpriestman

Thank you for your contribution.
Could you tell me how I can try using this test?

[benpriestman]

Hello @benpriestman

Thank you for your contribution. Could you tell me how I can try using this test?

Hi there,

You can read about Terraform tests here. These tests use mocked providers, so, you'll need to be running at least Terraform v1.7.0. I note that the module's current minimum version is v1.4.6.

The mocks mean that you don't need any credentials or a real infrastruture to run against. Effectively, they are unit tests, which just test the logic of the module itself, whether we can make a plan and whether that plan matches our expectations. They won't catch errors that only surface in a terraform apply. (Also note that, once a pattern is established, AI tools are pretty good at generating further tests and refining existing ones.)

To run the tests manually, just do:

terraform test

To run just one of them, do:

terraform test -filter tests/AndStatement.tftest.hcl

I see that you use precommit hooks for validation in this repo. I had a look at adding terraform test to these. However, the framework being used doesn't yet support this command. I see that there's an open issue to add support for this: antonbabenko/pre-commit-terraform#549.

As the tests have no dependencies other than an appropriate version of Terraform, it would be fairly simple to add a github workflow to run these against PRs. Do you think that this would be an acceptable complication?

All the above might be reasons for not adopting these tests fully. However, even if only run manually, I think you might find them useful when making changes. I'm happy to split this into two PRs: one for the type, one for the tests, if you might look more favourably on one than the other.

For context, I've been using similar tests and type definitions to develop an internal module, which calls yours. I can keep these in my module or a fork of yours but it would make more sense to put them in the module they are testing.

Give them a try and let me know what you think.

[uyggnodoow]

Hello @benpriestman

The changes to variables.tf are very clear. However, verifying them one by one is not easy, and adding a new optional field, for example, could cause errors.

Therefore, I want to exclude changes to variables.tf. What are your thoughts on this suggestion?