Run Pester Tests only on changed files (Git)

[crlgb]

Checklist

• Feature request has a meaningful title
• I have searched the existing issues. See all issues
• I have tested using the latest version of Pester. See Installation and update guide.

Summary of the feature request

As a user, I would like to be able to run pester tests only on changed files. These may either be the git differences between the current and last commit, or the current changes in the workspace.

In cases where the number and runtime of tests in a repository is very large, this would be extra helpful to test only the changes one made, before holistic testing is ran on CI/CD.

How should it work?

Invoke-Pester -GitChanges

[nohwnd]

#607 is your request similar to this?

[crlgb]

Similar, but not quite the same. The file system watcher is great for local development. The -GitChanges parameter would also allow Pester to be run only on changed files in CI/CD, e.g. on a new commit.

[fflaten]

Thank you for the suggestion. I'm a bit confused about the intended behavior. Should it track local uncommited changes or compare commit/branches (CI)?

These may either be the git differences between the current and last commit, or the current changes in the workspace.

Running e.g. Invoke-Pester -Path (@(git ls-files -m) -like 'tst/*.Tests.ps1') would test modified unstaged test files locally. Handling staged files, new files, exclude deleted etc. requires different commands though.

The -GitChanges parameter would also allow Pester to be run only on changed files in CI/CD, e.g. on a new commit.

With CI we'd have to diff the commit/target and base ref, e.g. (git diff --name-status target base) -match '^(A|M).*\.Tests.ps1$' -replace '^\S\s+'. The refs are provided in different environment variables specific to each CI platform.

Using git diff or a predefined action/task like https://github.com/marketplace/actions/changed-files in a workflow is an easy alternative for users.

Running only modified test files feels like a rare scenario for a CI, as you'd likely want to catch unexpected changes by testing the complete solution.

In general, we'd be taking a dependency on git and different CI-platforms which adds risk/support/maintenance, for a feature that is opinionated and very environment-specific. Would a documented example be a valid alternative?