Implementation Tracking: Mindev Rule Testing Framework

[krrish175-byte]

This issue tracks the implementation of the mindev test rule testing framework.
This work is being done as part of my LFX Mentorship project for this term

The design document for this framework has already been discussed and merged in PR #6492.

Implementation Phases

To make the review process smoother, the implementation will be broken down into the following logical phases and PRs:

• Phase 1: CLI Scaffolding and Test Discovery

  • Add cmd/dev/app/test/test.go to register the mindev test cobra command.
  • Implement a directory walker that finds all *.star files.
  • Set up a basic go.starlark.net execution environment that loads the files and scans the globals for any function starting with test_.
  • Invoke those functions using starlark.Call() and report success/failure.

• Phase 2: Core Starlark Builtins

  • Create pkg/ruletest (or internal/ruletest) to hold the core testing engine logic.
  • Implement pure-logic builtins: read_file(path) and txtar(string).
  • Implement the check module (check.eq, check.contains) with "expect semantics" (collecting errors in the Starlark thread-local storage rather than aborting immediately).

• Phase 3: The Mocking Layer

  • Implement HTTP mocking mechanisms.
  • Add builtins: body(payload) and code(status).
  • Create a custom http.RoundTripper that takes a dictionary of URL glob patterns to mock responses, and intercepts outbound requests.

• Phase 4: Engine Integration & eval() Builtin

  • Implement eval(rule, entity, mocks) to bridge to Minder's rule engine.
  • Read the associated *.yaml rule definition from the filesystem.
  • Wire up the mocked http.RoundTripper and mocked filesystem to pkg/engine.Evaluate().
  • Return the results (status and violations) back to Starlark.

Open Questions for Reviewers

1. Package placement: Does putting the core testing engine logic in pkg/ruletest (or internal/ruletest) sound good, so it's separate from the CLI boilerplate?
2. CLI command: Should the command be just mindev test or nested like mindev rule test?

[evankanderson]

I'd open sub-issues for different parts of the effort if it makes sense.

In terms of ordering, I'd probably start with trying to get the core bits together without necessarily worrying about the niceties of the final command surface. So this might mean a single starlark and rules file, and the core starlark and minder rules engine, without any providers / ingest to start with, and then build from there (move step 4 earlier). The goal is to surface any "big rocks" or uncertainties early in the process.

I'd probably aim to put the rule testing code in pkg, because it allows for other users / codebases to pick up the functionality. We don't have a strict versioning story (or usage) there yet so it's okay to make breaking changes.

[krrish175-byte]

That makes a lot of sense to start with the core engine integration to surface any big rocks early, and build outward from there. I will use pkg for the testing code. Creating sub-issues now