Table of Contents

Quality Assurance Tools

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.

Existing automated checks and when to run them

When changing Angular

Run the Angular Unit Tests

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

Run the Angular Linter

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

Run the Angular end-to-end nightwatch tests

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

When changing the database

Run the PgTAP tests

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.

When changing the Perl code

Run the Perl Unit tests

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

Run the Perl Live tests

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

Run the Perl author checks

  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

Run Perl::Critic

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

When changing the documentation

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 checks