feat: add --related* flags to run affected tests only#765
feat: add --related* flags to run affected tests only#765stephanschubert wants to merge 4 commits intolunarmodules:masterfrom
--related* flags to run affected tests only#765Conversation
Add new --related, --related-files, and --related-base CLI options that analyze code dependencies to run only tests affected by changes. Includes: - CLI argument parsing - Runner integration - busted/modules/related/ module suite - Rockspec updates
- 43 unit tests for RequireParser, PathResolver, DependencyGraph, GitChanges - 7 git integration tests with real temporary repos - Mock-based tests for deterministic git behavior - Test fixtures demonstrating dependency tracking
Add command context to error messages in git_changes for better debugging. Add input validation for rootFiles/patterns parameters in init.lua. Add optional verbose logging for parse failures in dependency_graph. Fix assertion style in integration tests (assert.equals -> assert.are.equal).
|
No, we're not going to start requiring Git at runtime and hard coding assumptions about the VCS people are using. I realize Git is pretty ubiquitous at this point, but I've been through two major migrations in VCS in the past (CVS→Subversion and Subversion→Git) and there are new players these days like Jujitsu. Blinding noticing a That's not to say that this isn't a useful feature for a test runner to accommodate, only that it needs to be architect ed differently. Busted as a test runner needs to accommodate receiving a list of tests somehow, then an external tool or plugin of some sort can be used to either call or as a callback to determine what to run based on VCS history. That's where this Git logic can be deployed. I haven't thought about this enough to suggest whether a callback (runner asks something else what to run) or wrapper (something else figures out what to run and calls the runner) approach would be best, but I'm pretty confident the direct approach with CLI flags hard coded to a certain Git VCS layout is not something I'm willing to include. |
| cli:flag('--[no-]sort-tests', 'sort test order within a file', processOption) | ||
| cli:flag('--[no-]suppress-pending', 'suppress `pending` test output', false, processOption) | ||
| cli:flag('--[no-]defer-print', 'defer print to when test suite is complete', false, processOption) | ||
| cli:flag('--related', 'only run tests related to uncommitted git changes. Note: dynamic requires like require(var) are not detected.', false, processOption) |
There was a problem hiding this comment.
The functionality directly baked into Busted should never assume Git is the VCS in charge.
|
iirc @eskerda added some extension mechanism I while back |
|
this PR #658 (haven't checked whether it handles this use case) |
3 participants
The
--relatedoption allows you to run only the tests that are affected by recent code changes. This is useful for faster feedback during development.Basic Usage
Run tests related to uncommitted git changes:
Run tests related to specific files (skips git, works anywhere):
Compare against a specific git ref instead of HEAD:
How It Works
require(),loadfile(), anddofile()statementsKnown Limitations
require(variable)orrequire("prefix" .. name)cannot be statically analyzedPerformance Considerations
For large codebases:
--verboseto see dependency graph statistics--related=fileswith explicit file lists for faster execution in CI