Skip to main content
Testing is crucial to ensuring the quality and reliability of NVDA. Whether you’re a developer testing your changes or a community member helping to test new releases, this guide will help you understand the testing process.

Important Resources

Types of Builds

Alpha Builds

  • Bleeding edge builds created directly from the master branch
  • Created each time a pull request is merged
  • Includes code being tested for possible inclusion in upcoming releases
  • May not be tested much and may contain major bugs
  • Automated tests pass, but likely had no user testing
Download alpha builds

Beta Releases

  • Beta quality builds
  • Include all features for the upcoming release that have proved stable in alpha
  • More stable than alpha builds
Download beta builds

Release Candidates (RC)

  • Usually identical to the final release
  • The latest final release will be identical to the final RC of the release cycle

Manual Testing

User and community testing is particularly important for languages other than English.

Testing Approaches

NVDA includes manual test plans to guide testers in smoke testing features. You can take several approaches:
Just use NVDA as you normally would and try to complete everyday tasks. This helps catch issues in real-world scenarios.
Forming a group can help you get good coverage, brainstorm on what should be tested, and learn new ways to use NVDA.

Automated Testing

NVDA performs automated testing as part of CI/CD, including linting checks, unit tests, and system tests.

Pre-commit Hooks

Pre-commit hooks automatically run linting, translatable string checks, and unit tests on files staged for commit. This will automatically apply lint fixes where possible and cancel commits on lint issues and test failures. Set up pre-commit for your NVDA environment:
uv run pre-commit install
Or set up globally:
pip install pre-commit
pre-commit install --allow-missing-config
Skip pre-commit hooks:
git commit -m "message" --no-verify

Manually Running Pre-commit Hooks

Run pre-commit hooks manually with filters:
# Run on specific files
uv run pre-commit run --files path/to/file.py

# Run on all files
uv run pre-commit run --all-files

# Compare two revisions
uv run pre-commit run --from-ref origin/master --to-ref HEAD

Translatable String Checks

Check that all translatable strings have translator comments:
runcheckpot.bat

Linting Your Changes

Our linting process uses:
  • Ruff - Python linting and auto-fixes
  • pyright - Static type checking
Run the linter:
runlint.bat
Integrate Ruff and pyright with your IDE to be warned about linting errors faster.

Unit Tests

Unit tests use the xmlrunner wrapper around Python’s unittest framework. Run all unit tests:
rununittests.bat
Run specific tests using the -k option:
rununittests -k test_cursorManager.TestMove -k test_cursorManager.TestSelection
The -k option can be provided multiple times to match against multiple patterns. Refer to unittest’s documentation for more information on filtering tests.

System Tests

System tests use the Robot test framework. Run standard tests for developers:
runsystemtests.bat --include NVDA
Run specific test tags:
runsystemtests.bat --include <TAG>
Any arguments given to runsystemtests.bat are forwarded to Robot. For more details including filtering and exclusion of tests, see tests/system/readme.md.

License Checks

NVDA uses GPLv2 which is incompatible with certain licenses like Apache. Check that you don’t introduce incompatible dependencies:
runlicensecheck.bat
This is configured in pyproject.toml using the licensecheck pip package.

Testing Checklist for Pull Requests

When submitting a pull request, ensure you’ve completed:
1

Manual testing

  • Test the change thoroughly in real-world scenarios
  • Test on all supported operating systems if applicable
  • Consider possible regressions in related features
  • Follow relevant manual test plans
2

Automated tests

rununittests.bat    # All tests must pass
runlint.bat         # No linting errors
runcheckpot.bat     # Translatable strings validated
runlicensecheck.bat # No license conflicts
3

Consider test coverage

  • Can your changes be covered by automated unit tests?
  • Can your changes be covered by automated system tests?
  • If this is a commonly tested part of NVDA, add your test steps to the manual test documentation

Community Communication Channels

Join the testing community:

Contributing as a Tester

You don’t need to be a developer to contribute to NVDA through testing! Testing alpha and beta releases, confirming bugs, and testing pull requests are all valuable contributions.
For more information on contributing through testing, see the contributing guide.

Release Process

Learn more about how NVDA releases are managed in the release process documentation.

Build docs developers (and LLMs) love