Evergreen contributors use several tools to make sure that they are not introducing new bugs and that their contributions will be readable and maintainable in the long term.

This page provides an overview of the various testing tools, what they do, and at which stage you would use them, with an emphasis on which ones you run vs which ones you write.

Running the Angular Unit Tests requires a running non-production Evergreen system. If you don't have one already, here's how to create a development/qa environment. You should run these at least twice: before and after you have made your Angular changes.

1. Install Firefox and/or Chrome on the system
2. In a terminal, cd to the Evergreen source code root (can be the git repository or a decompressed tarball)
3. cd Open-ILS/src/eg2
4. npm install
5. npm run test

You can run the angular linter with or without a running Evergreen system. Full information about the angular linter can be found here. You should run this before submitting your Angular changes for community review.

1. In a terminal, cd to the Evergreen source code root (can be the git repository or a decompressed tarball)
2. cd Open-ILS/src/eg2
3. npm install
4. npm run test

These tests can take some time to run, since they fire up a browser and click around the interface as a user would. They require a running non-production Evergreen system. You should run these before submitting your Angular changes for community review.

1. Install Firefox on the system
2. mkdir $HOME/tmp
3. In a terminal, cd to the Evergreen source code root (can be the git repository or a decompressed tarball)
4. cd Open-ILS/src/eg2
5. npm install
6. TMPDIR=$HOME/tmp MOZ_HEADLESS=1 npx nightwatch

Instructions for installing and running PgTAP tests. They require a running non-production Evergreen database. You should run these at least twice: before and after you have made your database changes.

These require a running OpenSRF system and for ./configure and make to have been run. You should run these before submitting your Perl changes for community review.

1. In a terminal, cd to the Evergreen source code root (can be the git repository or a decompressed tarball)
2. make check

These tests can take some time to run. They require a running non-production Evergreen system. You should run these before submitting your Perl changes for community review.

1. Load a fresh copy of the concerto data set using the Open-ILS/src/support-scripts/eg_db_config script.
2. In a terminal, cd to the Evergreen source code root (can be the git repository or a decompressed tarball)
3. cd Open-ILS/src/perlmods
4. make livecheck

1. If you have not installed it yet, cpan Test::Pod
2. In a terminal, cd to the Evergreen source code root (can be the git repository or a decompressed tarball)
3. cd Open-ILS/src/perlmods
4. prove xt/author

This is not a required step. However, it can be very informative, especially if you are new to Perl.

• You can copy/paste the code you're interested in into the Perl::Critic analyzer web site
• You can run perlcritic from the command line.

Vale checks our documentation to make sure it matches our style guide. Vale checks have not yet been merged into Evergreen. In the meantime, you can find our community Vale configuration in a git branch linked from the vale launchpad ticket.

• Writing new angular tests
• Writing new pgTAP tests