You've fixed a bug in Evergreen! That's great! Let's prevent it from happening again in the future. After all, most bugs happen because they are perfectly reasonable mistakes to make. Including one or more of the following techniques when you submit your bug fix can provide a safety net for future contributors to make sure they don't inadvertently damage your contribution.

If the bug was something specific to this component, for example, it displayed its data incorrectly or a user interaction was broken: an angular unit test can be useful.

If the bug was a general bad practice that could happen in any component (for example, important @Inputs not marked for translation, CSS classes combined that don't look good together, broken accessibility semantics), try writing a custom ESLint rule.

Angular unit tests are useful for guarding against regressions in the typescript code, whether it is in a component, service, or elsewhere.

Note that Angular unit tests are relatively easy to write for components, services, etc. that have one job and do it well. Unfortunately, the Angular client has many very complex typescript classes with many responsibilities and many dependencies, which makes it much more difficult to test them in isolation. Simple mocks of common services can be found in Open-ILS/src/eg2/src/test_data/mock_generators.ts.

* Example typescript bugfix that includes an angular test

A pgtap test is just what you need! If it is easy to test without a lot of seed data, put it in the t directory. If it requires a lot of seed data from the concerto data set, put it in the live_t directory.

• Example pgtap test that accompanies a bug fix

You can write a C unit test. These can be quite difficult to do if the particular C function can't easily be called in isolation. In those cases, a Perl live test is often a simpler and clearer way to go!

• Example of a Perl live test testing a bugfix in the C code

To guard against regressions in the IDL, you could write a perl unit test that parses the fm_IDL.xml file and makes assertions against it. I don't know of any examples of this type of test (yet!) at the time of writing.

TT2 files can be tested using a Perl unit test.

Here's an example of a basic test (intended as a starting point, it has a few issues as noted below):

use strict; use warnings;
use Test::More tests => 1;
use Template;
use FindBin qw($Bin);
use Carp;

my $filename = 'opac/parts/myopac/prefs_hints.tt2';

my $tt = Template->new({
    INCLUDE_PATH => ["$Bin/../../templates-bootstrap", "$Bin/../../templates"],
    PLUGINS => {
        CGI_utf8 => 'OpenILS::WWW::EGWeb::CGI_utf8'
    }
});

my $output;
$tt->process(
    $filename,
    {}, # This is where you would set any variables that are needed for the template
    \$output
) or croak $tt->error;
like $output, qr/<p/, 'it is structured as a <p> tag';

Be careful of testing very specific details of the templates. If your assertion could theoretically fail without necessarily indicating a problem, find a different way of testing it. For example, the above example could fail in several ways that don't necessarily indicate a problem:

• The filename of the tt2 file changes
• The tt2 file switches to some other markup that is just as good as a <p> tag

The above example test could also be tricked! For example, if the template had a <pre> tag but no <p> tag, the test would pass despite having incorrect markup. Similarly, this test never asserts that the <p> tag is closed within the template, or indeed that the HTML syntax is correct in any way. A more reliable test could perhaps use HTML::TreeBuilder to parse the $output string and make more trustworthy (and readable) assertions.

Note that you can iterate through multiple tt2 templates (or even all of them!) in the same test, so it can be a good option if there are certain bad practices that you want to catch regardless throughout the tt2 code base.

• An example test that checks every tt2 file in the src directory

Some javascript files in the OPAC are EcmaScript modules (i.e. they use import and export). You can validate fixes to these files by adding a test to Open-ILS/web/opac/tests.

If the javascript file in question is not yet an EcmaScript module, you may consider refactoring it to be one – not only does this help with testability, but have the added benefit of not blocking the browser from rendering.

• Example of an OPAC javascript bugfix with a unit test

• Adding a comment about why you use a particular approach is always welcome.
• A clear, descriptive commit message without unnecessary jargon.