Skip to content

feat(mindev): add --junit-file flag to test command and add Starlark testing docs - #6690

Open
krrish175-byte wants to merge 1 commit into
mindersec:mainfrom
krrish175-byte:feat/mindev-test-junit-file
Open

feat(mindev): add --junit-file flag to test command and add Starlark testing docs#6690
krrish175-byte wants to merge 1 commit into
mindersec:mainfrom
krrish175-byte:feat/mindev-test-junit-file

Conversation

@krrish175-byte

Copy link
Copy Markdown
Member

Addresses feedback to support writing JUnit XML to a specific file while preserving standard terminal output. Also adds Starlark testing documentation to the mindev how-to docs.

@krrish175-byte
krrish175-byte requested a review from a team as a code owner August 11, 2026 06:36
@coveralls

Copy link
Copy Markdown

Coverage Status

coverage: 61.671%. remained the same — krrish175-byte:feat/mindev-test-junit-file into mindersec:main

@evankanderson evankanderson left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm probably going to hold off on cutting a release until we figure out if there are any other mindev changes you'll want for tests.


## Testing with Starlark

In addition to evaluating rules against a single entity, `mindev test` allows you to run comprehensive Starlark-based tests against your rule types. This is the recommended way to verify rule behavior, as it lets you mock external systems like GitHub REST/GraphQL APIs and Git filesystems.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two comments:

  1. It's probably worth linking to the starlark language documentation, so people can understand what's supported.
  2. I'd make a stronger statement than "recommended way" -- something like "mindev test is the supported mechanism for verifying rule behavior, and is designed for integration into CI/CD pipelines as well as standalone usage".

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to add this usage here, but we should think about a standalone page describing "how to test rules".

This would cover both manual and automated (CI) testing, including referencing the action and examples of setup, as well as some hints on effective testing usage, and documentation of the custom functions added to the starlark runtime.

)

# 4. Assert the result
assert result["status"] == "success", "Expected rule to pass"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the expanded page, we should include information about what entries are in the "result" object, as well as the input arguments to "eval".

assert result["status"] == "error", "Expected rule to fail"
```

The `eval` builtin takes several optional arguments:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these arguments are not optional (at a minimum, the "rule" argument, and maybe the "entity" argument).

@evankanderson

Copy link
Copy Markdown
Member

Feel free to either merge this, or address some of the PR feedback and have me do another review (I'm fine with either, holding off on hitting merge to give you the choice).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants