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.
cd
to the Evergreen source code root (can be the git repository or a decompressed tarball)cd Open-ILS/src/eg2
npm install
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.
cd
to the Evergreen source code root (can be the git repository or a decompressed tarball)cd Open-ILS/src/eg2
npm install
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.
mkdir $HOME/tmp
cd
to the Evergreen source code root (can be the git repository or a decompressed tarball)cd Open-ILS/src/eg2
npm install
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.
cd
to the Evergreen source code root (can be the git repository or a decompressed tarball)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.
Open-ILS/src/support-scripts/eg_db_config
script.cd
to the Evergreen source code root (can be the git repository or a decompressed tarball)cd Open-ILS/src/perlmods
make livecheck
cpan Test::Pod
cd
to the Evergreen source code root (can be the git repository or a decompressed tarball)cd Open-ILS/src/perlmods
prove xt/author
This is not a required step. However, it can be very informative, especially if you are new to Perl.
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.