====== Preventing regressions ======

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.

===== Angular component templates =====

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 typescript =====


===== Database functions =====

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.

===== Perl logic =====

===== C logic =====

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 can do the trick!


===== IDL problems =====

===== TT2 problems =====


===== OPAC Javascript problems =====


===== General =====

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