test(cli): add coverage for catalog validation edge cases

[sachin9058]

Summary

This PR adds test coverage for catalog validation logic, focusing on edge cases and behavior when handling invalid or incomplete data.

It is based on the catalog loading and validation changes introduced in #6364 and is part of a stacked PR sequence.

Motivation

The catalog loading flow introduces validation logic that filters invalid profiles and ensures rule type references are correct. Adding tests for these scenarios improves confidence in the behavior and prevents regressions in edge cases.

Changes

Added tests for Catalog.Validate covering:

• Nil catalog handling

  • Ensures validation does not panic and returns an error

• Empty catalog

  • Verifies that a catalog with no rule types or profiles is handled correctly

• Valid catalog

  • Confirms that profiles referencing existing rule types pass validation

• Invalid rule references

  • Ensures profiles referencing missing rule types are skipped while valid profiles are preserved

Behavior Verified

• Validation does not panic on invalid inputs
• Profiles with missing rule type references are excluded
• Valid profiles remain intact after validation
• Error conditions are surfaced appropriately

Stacked PR Context

This PR depends on #6364, which introduces the catalog loading and validation logic.

To keep changes small and reviewable:

• #6364focuses on implementation
• This PR focuses on test coverage

Once #6364 is merged, this PR will only contain the test changes.

Testing

All tests pass locally:

go test ./...

Notes

This PR intentionally focuses on behavior validation rather than implementation details, ensuring flexibility if the underlying logic evolves.

[coveralls]

Coverage is 60.225% — sachin9058:test/catalog-loading-v2 into mindersec:main. No base build found for mindersec:main.

[evankanderson]

Just a few comments on the tests -- I think it's reasonable (and good!) to include the tests alongside the PR, so I would fold this into #6364 that it's built on.

That also makes it easier to check whether the overall coverage went up or down when reviewing the PR.

[evankanderson]

Since Catalog isn't implementing an interface, you don't need to take a reference here -- it's fine to build it on the stack.

[evankanderson]

These feel like they would fit the Go data-driven test case pattern used in internal/util/cli/cli_test.go et al very well.

(Also, why introduce a new directory, rather than re-using internal/util/cli?)

[sachin9058]

@evankanderson Thanks for the feedback

I’ve merged the test coverage into #6364 so implementation and tests are reviewed together.

I’ve also:

• converted the tests to a table-driven format to align with existing patterns
• removed unnecessary pointer usage where not needed

For now I’ve kept the tests alongside the catalog logic in internal/cli, but I’m happy to move them to internal/util/cli if that’s preferred.

Let me know if this looks better aligned.