Most of Evergreen's business logic can be found in perl modules. In the git repository, these can be found at Open-ILS/src/perlmods/lib. Perl modules typically have the .pm file extension.

Evergreen's business logic is tested by the tests in Open-ILS/src/perlmods/t (which do not require the concerto data set to be running in the database) and Open-ILS/src/perlmods/live_t (which do). Perl tests have the .t file extension. The perl code is also exercised indirectly by the end-to-end tests for the Angular staff client.

There are many Perl scripts throughout the project. Perl scripts generally have the .pl file extension.

Evergreen's Perl code relies on many packages from CPAN. They are installed by your operating system's package manager and cpan itself when you run the Open-ILS/src/extras/Makefile.install Makefile. When you need to add or remove a dependency, do so for all of the operating systems listed in the Open-ILS/src/extras/install directory.

Here are some things you can do to check your work while working with Evergreen's perl code:

• If it is in an OpenSRF method: Build it, install it, and restart your services. Then call the method (through the UI, or directly using the srfsh). Confirm that the behavior is what you expected.
• Write some tests to confirm that your code is working as intended, without any unintended side effects.
• Run `perl -cw [name of file]` to check your syntax and check for warnings.
• Run perlcritic on your code to check for common gotchas and readability. You can paste your code directly into the online PerlCritic checker. This is not a requirement (most perl code in Evergreen violates these rules), but it can be very instructive.
• Temporarily adding print or logging statements to your work. If you'd like to print an array or hash, try using Data::Dumper.

• Making Perl Work for You in Evergreen, by Galen Charlton & Mike Rylander