Running Tests

Relevant source files

The following files were used as context for generating this wiki page:

• iac-recert-engine/internal/engine/engine_test.go
• iac-recert-engine/internal/scan/recert_checker_test.go
• iac-recert-engine/test-config.yaml
• iac-recert-engine/internal/scan/file_scanner_test.go
• iac-recert-engine/internal/config/types_test.go
• iac-recert-engine/internal/strategy/strategy_test.go
• iac-recert-engine/internal/assign/resolver_test.go

The iac-recert-engine project utilizes a suite of unit and integration tests written in Go to ensure the correctness and reliability of its components. The tests leverage the standard testing package along with the stretchr/testify library for assertions. A key testing strategy involves creating temporary, local Git repositories to simulate real-world conditions for scanning and engine execution without network dependencies.

Tests are organized by package and cover core functionalities including the main engine logic, file scanning, recertification checking, configuration validation, and PR grouping strategies. Test scenarios are often driven by structured configuration objects, mirroring the application's production configuration (config.yaml).

Test Configuration

Tests rely on configuration files and in-code structs to define the behavior of the engine and its components for a given test run. The test-config.yaml file serves as a comprehensive example of the available settings.

Sources: test-config.yaml, internal/engine/engine_test.go:27-58

Configuration Structure

The main Config struct is validated in TestConfig_Validate to ensure that invalid configurations are caught early. Tests cover missing required fields and invalid enum values for providers and strategies.

Sources: internal/config/types_test.go:10-184

The table below outlines key configuration sections used in tests, as seen in test-config.yaml and engine_test.go.

Section	Description	Example from test-config.yaml
repository	Specifies the target repository URL and provider type.	`url: "https://github.com/baldator/iac-recert-engine%22%60
auth	Defines the authentication method, typically an environment variable for a token.	token_env: "GITHUB_TOKEN"
global	Global settings like dry_run mode.	dry_run: false
patterns	Defines file patterns to scan, including paths, exclusion rules, and recertification periods.	name: "terraform-prod", paths: ["terraform/prod/**/*.tf"]
pr_strategy	Determines how files needing recertification are grouped into pull requests.	type: "per_pattern"
assignment	Defines the strategy for assigning pull requests to users or teams.	strategy: "composite"
pr_template	Configures the title and content of the generated pull requests.	title: "🔄 Recertification: {pattern_name}"

Sources: test-config.yaml, internal/engine/engine_test.go:27-58, internal/config/types.go

Engine Tests

The tests for the main engine are located in internal/engine/engine_test.go. They cover the initialization of the engine and its main Run function under various conditions.

Sources: internal/engine/engine_test.go

TestNewEngine

This test verifies that the engine can be successfully instantiated with a valid configuration. It ensures that the configuration and logger are correctly assigned to the engine struct. A dummy GITHUB_TOKEN is set as an environment variable for the test to pass authentication setup.

Sources: internal/engine/engine_test.go:17-59

TestEngine_Run

This function contains several sub-tests for the Run method, which is the primary entry point for the recertification process.

• Dry Run: A test case confirms that the engine can execute in dry_run mode. While it's expected to return an error due to mock network operations, the test ensures it exercises the dry run code path without panicking.
• Scan Failure: This test uses an invalid repository URL to confirm that the engine correctly handles and reports errors during the initial scan phase.
• Full Run with Local Repo: This is the most comprehensive engine test. It simulates a full execution cycle by creating a temporary local Git repository.

The diagram below illustrates the setup for the local repository test.

This diagram shows the process of setting up a temporary git repository to test the engine's run cycle.

Sources: internal/engine/engine_test.go:167-221

The following code snippet shows how the temporary git repository is initialized and configured for the test.

// iac-recert-engine/internal/engine/engine_test.go:170-181
// Create a temporary git repository for testing
tmpDir, err := os.MkdirTemp("", "engine-test-repo")
require.NoError(t, err)
defer os.RemoveAll(tmpDir)

// Create test files
testFile := filepath.Join(tmpDir, "main.tf")
err = os.WriteFile(testFile, []byte("resource \"aws_instance\" \"test\" {}"), 0644)
require.NoError(t, err)

// Initialize git repo
require.NoError(t, exec.Command("git", "init", tmpDir).Run())
require.NoError(t, exec.Command("git", "-C", tmpDir, "add", ".").Run())
require.NoError(t, exec.Command("git", "-C", tmpDir, "config", "user.email", "test@example.com").Run())
require.NoError(t, exec.Command("git", "-C", tmpDir, "config", "user.name", "Test User").Run())
require.NoError(t, exec.Command("git", "-C", tmpDir, "commit", "-m", "Initial commit").Run())

Component Tests

Individual components of the engine are tested in isolation to verify their specific logic.

Scanner Tests

TestScanner_Scan in internal/scan/file_scanner_test.go verifies that the file scanner correctly identifies files based on glob patterns defined in the configuration. It also tests that enabled: false patterns are skipped and exclude paths are respected. Like the engine test, it uses a temporary directory with a mock file structure and a git repository.

Sources: internal/scan/file_scanner_test.go

Test Case	Patterns	Expected Matched Files
match terraform files	paths: ["**/*.tf"]	main.tf, modules/vpc/main.tf, modules/vpc/variables.tf
match markdown files	paths: ["**/*.md"]	README.md
exclude variables.tf	paths: ["**/*.tf"], exclude: ["**/variables.tf"]	main.tf, modules/vpc/main.tf
disabled pattern	enabled: false, paths: ["**/*.tf"]	(none)

Sources: internal/scan/file_scanner_test.go:49-112

Recertification Checker Tests

TestChecker_Check in internal/scan/recert_checker_test.go focuses on the core logic of determining if a file needs recertification. It provides FileInfo with varying LastModified dates and checks if the RecertCheckResult has the correct NeedsRecert status and Priority.

The following sequence diagram shows the data flow within a checker test.

This diagram depicts the interaction between the test function and the Checker component to verify recertification logic.

Sources: internal/scan/recert_checker_test.go

The tests cover different scenarios for priority calculation:

Scenario	Days Since Last Modified	Threshold (Days)	Expected Priority	Needs Recert
critical	100	60	Critical	true
high	70	60	High	true
approaching threshold	50	60	Medium	false
no recert needed	10	60	Low	false

Sources: internal/scan/recert_checker_test.go:25-132

Strategy and Assignment Tests

• Strategy Tests: internal/strategy/strategy_test.go contains tests for each grouping strategy (per_file, per_pattern, per_committer, single_pr). Each test provides a list of RecertCheckResult objects and asserts that the Group function produces the expected number of groups with the correct files.
• Assignment Tests: internal/assign/resolver_test.go verifies the logic for assigning PRs. For example, the last_committer strategy test checks that the assignee is correctly identified as the author of the most recent commit among the files in the group.

Sources: internal/strategy/strategy_test.go, internal/assign/resolver_test.go