User Tools

Site Tools


qa:preventing_regressions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
qa:preventing_regressions [2025/07/09 09:36] – [Preventing regressions] sandbergjaqa:preventing_regressions [2025/07/30 09:35] (current) – [IDL problems] sandbergja
Line 13: Line 13:
  
 If the bug was a general bad practice that could happen in any component (for example, important ''@Input''s not marked for translation, CSS classes combined that don't look good together, broken accessibility semantics), try writing a custom ESLint rule.  These will check all templates that don't specifically opt out, so it's a good way to do these checks at scale. If the bug was a general bad practice that could happen in any component (for example, important ''@Input''s not marked for translation, CSS classes combined that don't look good together, broken accessibility semantics), try writing a custom ESLint rule.  These will check all templates that don't specifically opt out, so it's a good way to do these checks at scale.
 +
 +If the bug was a general accessibility bug (e.g. form inputs not associated with their labels), another nice option is a nightwatch end-to-end (e2e) test.  Nightwatch can load your page in a browser then [[https://nightwatchjs.org/guide/using-nightwatch/accessibility-testing.html|run aXe automated checks against it]].
  
   * [[https://github.com/evergreen-library-system/Evergreen/commit/1a3e59375f408b4aa99d95e320d0810026668412|Example tests that make assertions about an addition to a template]] (although this is in the context of a new Angular feature rather than a bug fix)   * [[https://github.com/evergreen-library-system/Evergreen/commit/1a3e59375f408b4aa99d95e320d0810026668412|Example tests that make assertions about an addition to a template]] (although this is in the context of a new Angular feature rather than a bug fix)
   * [[https://bugs.launchpad.net/evergreen/+bug/2019139|Example ESLint rule]] (not yet committed)   * [[https://bugs.launchpad.net/evergreen/+bug/2019139|Example ESLint rule]] (not yet committed)
 +  * [[https://github.com/evergreen-library-system/Evergreen/commit/d04b1469d84c0adf9b161ea16f0e2d6b5fd71fb8|Example nightwatch test]] that accompanies a fix of two accessibility issues: an image missing alt text and missing landmark roles.
 ===== Angular typescript ===== ===== Angular typescript =====
  
Line 43: Line 46:
  
   * [[https://github.com/evergreen-library-system/Evergreen/commit/0458ae01ef6a84734efb7232bc1cdaf479dd3be8|Example of a Perl live test testing a bugfix in the C code]]   * [[https://github.com/evergreen-library-system/Evergreen/commit/0458ae01ef6a84734efb7232bc1cdaf479dd3be8|Example of a Perl live test testing a bugfix in the C code]]
-===== IDL problems =====+===== IDL and other XML problems ===== 
 + 
 +To ensure that the IDL (or other XML file) is in a consistent format, you can adjust the XML schema (*.xsd) files.  For example, [[https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=e71d0ce1360c4a28d4b23c440e227548228c70fc|this commit adjusts the schema]] to specify that classes in the IDL may have an attribute named "cardinality", but that it must have one of three values: low, high, or unbounded.
  
-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.+To guard against more complex 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 problems ===== ===== TT2 problems =====
  
Line 90: Line 95:
 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. 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.+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 EcmaScript modules have the added benefit of not blocking the browser from rendering.
  
   * [[https://github.com/evergreen-library-system/Evergreen/commit/dcca92e1d995a1343023c442661c73d024caadf9|Example of an OPAC javascript bugfix with a unit test]]   * [[https://github.com/evergreen-library-system/Evergreen/commit/dcca92e1d995a1343023c442661c73d024caadf9|Example of an OPAC javascript bugfix with a unit test]]
Line 97: Line 102:
   * Adding a comment about why you use a particular approach is always welcome.   * Adding a comment about why you use a particular approach is always welcome.
   * A clear, descriptive commit message without unnecessary jargon.   * A clear, descriptive commit message without unnecessary jargon.
 +  * If your test required some extra data beyond what is available in the Concerto Data Set or Enhanced Concerto Data Set, consider adding that data to make things easier for human testers.
qa/preventing_regressions.1752068190.txt.gz · Last modified: 2025/07/09 09:36 by sandbergja

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.