Contributing Guide

September 2, 2026 · View on GitHub

First of all, Welcome! :wave: and thank you for your interest in contributing to our UI testing framework.

Feedback

Issues

Have you a question? Have you found a problem 🚫 you would like to see fixed? Is there something you would like to see improved or features 🚀 added?

Then we'd like to hear from you. Hop on to the issue tracker and create an issue. If you would check if a similar issue already exists beforehand, it would be much appreciated :heart:.

If you happen to find an existing issue or a pull request that interests you, feel free to comment or upvote :+1: / downvote :-1: to give us your opinion (we do prefer comments over votes).

Code, Building, Testing and Pull Requests

If submitting issues just doesn't cut it for you, we are always happy to see code contributions. Here are a few steps to get your code in as fast as possible:

Get the Code

The first step is to fork this repository and clone your new fork. We also recommend adding the upstream as a new remote so you can easily get updates.

git clone https://github.com/<your user name>/vscode-extension-tester
cd vscode-extension-tester
git remote add upstream https://github.com/redhat-developer/vscode-extension-tester

Build It

Now that you have the code, you will need to build the project. First, we need to install all modules dependencies:

npm install

Test It

When you make a change, make sure the tests are passing. In the tests/test-project directory there is a dummy VS Code extension we use to test the framework itself.

For that, you can use the following script and launch the tests:

npm run test:build

If you are adding a new feature, be sure to write new tests for it. If you navigate to the tests/test-project/src/test folder, you will find a test file structure that mirrors the source files. Put your new test into the appropriate existing file, or create a new one that follows the same structure.

Coverage

Two workflows measure coverage, and neither needs the tests to pass: V8 writes its coverage data when a process exits, so failed tests still count for the code they ran.

  • Framework coverage (the 📊 Framework Coverage job in Main CI): the ubuntu cells of every suite job collect V8 coverage of the ExTester runner process while the UI tests run, and one final job merges them into a report of how much of packages/* the tests exercise. The numbers are in that job's summary; the HTML and lcov report is the framework-coverage artifact. It is informational only and not part of the status check.
  • Sample-extension coverage (the Code Coverage workflow): runs extest --coverage against tests/test-project nightly and on demand, as a smoke test of the coverage feature itself. It fails only when no report is produced.

The framework report is configured in .github/c8-framework.json. Do not add a .c8rc* or .nycrc* file to the repository root: extest --coverage discovers such files by walking up from the directory it runs in, so a root file would silently reconfigure the sample-extension report.

Documentation

User documentation lives in docs-site/ and is published to the documentation site. Update the relevant page in the same pull request as a behaviour or API change.

The root README.md is also the README of the vscode-extension-tester npm package: packages/extester/README.md is generated from it by the package build script and is not tracked in git, so edit the root file only.

Pull Requests

Having made and tested your changes, we recommend committing them into a new branch:

git checkout -b <my-new-branch>
git add <changed files>
git commit -m <type>(optional scope): <description> # see https://www.conventionalcommits.org/en/v1.0.0/#summary
git push origin <my-new-branch>

Now the changes are in a new branch in your fork, you can submit a new pull request. If your pull request is intended to fix an issue in the tracker, make sure to link the two together.

Lastly, a pull request check on Github Actions is going to kick in whenever a change is pushed. Please make sure it ends up green. Otherwise it might need a change on your part. Or maybe it also needs a change on our part - in that case opening a new issue is the best way to go.

Automated VS Code Version Updates

ExTester automatically maintains support for the latest 3 stable VS Code releases. See Automated Version Updates for full details.

For Maintainers

When the automated workflow creates a version update PR:

  1. Review the PR - Check which versions are being updated
  2. Wait for CI - Tests run automatically against all 3 versions
  3. Check test results - Look for any failures or breaking changes
  4. Merge if green - If all tests pass, merge the PR
  5. Consider release - Decide if a new release is needed

Manual trigger: You can manually run the Update VS Code Version Window workflow if needed.

Release new ExTester version

  • Check all related PR's were merged and the Main CI is green
  1. Execute npm run version
    • commit changes and open new PR
    • wait for PR is approved and merged
    • after merge, wait until Main CI is green
  2. Execute npm run publish
    • create and push new vX.X.X tag
    • create a new GitHub release from a new vX.X.X tag (with generated release notes)

Post publish tasks

  • Close published version milestone and update ExTester project board
  • Update vscode-extension-tester-example project
    • Merge PR's opened by Dependabot
    • Check Main CI build is green
  • (optional) Spread a message about new release using IM tools, mailing lists and social media

DCO

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.

See the DCO file for the details.