From 90ee61d5b681295b8b401128ca9bc48554eee66a Mon Sep 17 00:00:00 2001 From: =?utf8?q?Janek=20Warcho=C5=82?= Date: Tue, 14 Feb 2012 11:31:59 +0100 Subject: [PATCH] CG: add information about Regtest Checking Project Phil Holmes wrote a nice web app that allows people to review regtests, one at a time. We can ask users for help and thus painlessly do a full regtest check. This commit contains brief instructions how to use the app. --- Documentation/contributor/regressions.itexi | 44 +++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/Documentation/contributor/regressions.itexi b/Documentation/contributor/regressions.itexi index b23e6b1abb..aa5aeaa4e6 100644 --- a/Documentation/contributor/regressions.itexi +++ b/Documentation/contributor/regressions.itexi @@ -10,6 +10,7 @@ * Finding the cause of a regression:: * Memory and coverage tests:: * MusicXML tests:: +* Grand Regression Test Checking:: @end menu @@ -470,3 +471,46 @@ available in the LilyPond documentation: @uref{http://lilypond.org/doc/latest/input/regression/musicxml/collated-files} @end example + +@node Grand Regression Test Checking +@section Grand Regression Test Checking + +@subheading What is this all about? + +Regression tests (usually abbreviated "regtests") is a collection +of @file{.ly} files used to check whether LilyPond is working correctly. +Example: before version 2.15.12 breve noteheads had incorrect width, +which resulted in collisions with other objects. After the issue was fixed, +a small @file{.ly} file demonstrating the problem was added to the regression +tests as a proof that the fix works. If someone will accidentally break +breve width again, we will notice this in the output of that regression test. + +We are asking you to help us by checking a regtest or two from time to time. +You don't need programming skills to do this, not even LilyPond skills - +just basic music notation knowledge; checking one regtest takes less than +a minute. Simply go here: + +@example +@uref{http://www.holmessoft.co.uk/homepage/private/regtests/} +@end example + +@subheading Some tips on checking regtests + +@subsubheading Description text + +The description should be clear even for a music beginner. +If there are any special terms used in the description, +they all should be explained in our @rglosnamed{Top, Music Glossary} +or @rinternalsnamed{Top, Internals Reference}. +Vague descriptions (like "behaves well", "looks reasonable") shouldn't be used. + +@ignore +@subsubheading Is regtest straightforward and systematic? + +Unfortunately some regtests are written poorly. A good regtest should be +straightforward: it should be obvious what it checks and how. Also, it +usually shouldn't check everything at once. For example it's a bad idea to test +accidental placement by constucting one huge chord with many suspended notes +and loads of accidentals. It's better to divide such problem into a series +of clearly separated cases. +@end ignore -- 2.39.2