1 @c -*- coding: utf-8; mode: texinfo; -*-
3 @chapter Regression tests
6 * Introduction to regression tests::
7 * Precompiled regression tests::
8 * Compiling regression tests::
9 * Identifying code regressions::
10 * Memory and coverage tests::
15 @node Introduction to regression tests
16 @section Introduction to regression tests
18 LilyPond has a complete suite of regression tests that are used
19 to ensure that changes to the code do not break existing behavior.
20 These regression tests comprise small LilyPond snippets that test
21 the functionality of each part of LilyPond.
23 Regression tests are added when new functionality is added to
24 LilyPond. They are also added when bugs are identified. The
25 snippet that causes the bug becomes a regression test to verify
26 that the bug has been fixed.
28 The regression tests are compiled using special @code{make}
29 targets. There are three primary uses for the regression
30 tests. First, successful completion of the regression tests means
31 that LilyPond has been properly built. Second, the output of the
32 regression tests can be manually checked to ensure that
33 the graphical output matches the description of the intended
34 output. Third, the regression test output from two different
35 versions of LilyPond can be automatically compared to identify
36 any differences. These differences should then be manually
37 checked to ensure that the differences are intended.
39 Regression tests (@qq{regtests}) are available in precompiled form
40 as part of the documentation. Regtests can also be compiled
41 on any machine that has a properly configured LilyPond build
45 @node Precompiled regression tests
46 @section Precompiled regression tests
48 @subheading Regression test output
50 As part of the release process, the regression tests are run
51 for every LilyPond release. Full regression test output is
52 available for every stable version and the most recent development
55 Regression test output is available in HTML and PDF format. Links
56 to the regression test output are available at the developer's
57 resources page for the version of interest.
59 The latest stable version of the regtests is found at:
62 @uref{http://lilypond.org/doc/stable/input/regression/collated-files.html}
65 The latest development version of the regtests is found at:
68 @uref{http://lilypond.org/doc/latest/input/regression/collated-files.html}
72 @subheading Regression test comparison
74 Each time a new version is released, the regtests are
75 compiled and the output is automatically compared with the
76 output of the previous release. The result of these
77 comparisons is archived online:
80 @uref{http://lilypond.org/test/}
83 The test comparison shows all of the changes that occured between
84 the current release and the prior release. Each test that has
85 a significant difference in output is displayed, with the old
86 version on the left and the new version on the right. Blurs
87 in the regression tests for the new version show the approximate
88 location of elements in the old version.
90 Regression tests whose output is the same for both versions are not
91 shown in the test comparison.
93 Checking these pages is a very important task for the LilyPond project.
94 You are invited to report anything that looks broken, or any case
95 where the output quality is not on par with the previous release,
96 as described in @rweb{Bug reports}.
99 The automatic comparison of the regtests checks the
100 LilyPond bounding boxes and the log files. This means that
101 Ghostscript changes and changes in
102 lyrics or text are not found. However, errors and warnings that
103 are printed to the log file but
104 do not change the graphical layout are also identified.
107 Periodic manual checking of the
108 complete regtest output should be performed to catch anything
109 missed by the automatic comparison.}
111 @node Compiling regression tests
112 @section Compiling regression tests
114 Developers may wish to see the output of the complete regression
115 test suite for the current version of the source repository
116 between releases. Current source code is available; see
117 @ref{Working with source code}. Then you will need
118 to build the LilyPond binary; see @ref{Compiling LilyPond}.
120 Uninstalling the previous LilyPond version is not necessary, nor is
121 running @code{make install}, since the tests will automatically be
122 compiled with the LilyPond binary you have just built in your source
125 From this point, the regtests are compiled with:
131 If you have a multi-core machine you may want to use the @option{-j}
132 option and @var{CPU_COUT} variable, as
133 described in @ref{Saving time with CPU_COUNT}.
134 For a quad-core processor the complete command would be:
137 make -j5 CPU_COUNT=5 test
140 The regtest output will then be available in
141 @file{input/regression/out-test}.
142 @file{input/regression/out-test/collated-examples.html}
143 contains a listing of all the regression tests that were run,
144 but none of the images are included. Individual images are
145 also available in this directory.
147 The primary use of @samp{make@tie{}test} is to verify that the
148 regression tests all run without error. The regression test
149 page that is part of the documentation is created only when the
150 documentation is built, as described in @ref{Generating documentation}.
151 Note that building the documentation requires more installed components
152 than building the source code, as described in
153 @ref{Requirements for building documentation}.
156 @node Identifying code regressions
157 @section Identifying code regressions
159 Before modified code is committed to master, a regression test
160 comparision must be completed to ensure that the changes have
161 not caused problems with previously working code. The comparison
162 is made automatically upon compiling the regression test suite
165 Before making changes, a baseline should be established by running:
171 After making the changes, the code should be checked by running:
177 After @samp{make@tie{}check} is complete, a regression test comparison
178 will be available at @file{out/test-results/index.html}.
179 For each regression test that differs between the baseline and the
180 changed code, a regression test entry will displayed. Ideally, the
181 only changes would be the changes that you were working on. If
182 regressions are introduced, they must be fixed before committing the
186 The special regression test @file{test-output-distance.ly} will always
187 show up as a regression. This test changes each time it is run, and
188 serves to verify that the regression tests have, in fact, run.}
190 @node Memory and coverage tests
191 @section Memory and coverage tests
193 In addition to the graphical output of the regression tests, it is
194 possible to test memory usage and to determine how much of the source
195 code has been exercised by the tests.
197 @subheading Memory usage
199 For tracking memory usage as part of this test, you will need
200 GUILE CVS; especially the following patch:
201 @uref{http://www.lilypond.org/vc/old/gub.darcs/patches/guile-1.9-gcstats.patch}.
203 @subheading Code coverage
205 For checking the coverage of the test suite, do the following
208 ./scripts/auxiliar/build-coverage.sh
209 @emph{# uncovered files, least covered first}
210 ./scripts/auxiliar/coverage.py --summary out-cov/*.cc
211 @emph{# consecutive uncovered lines, longest first}
212 ./scripts/auxiliar/coverage.py --uncovered out-cov/*.cc
217 @section MusicXML tests
220 LilyPond comes with a complete set of regtests for the
221 @uref{http://www.musicxml.org/,MusicXML} language. Originally
222 developed to test @samp{musicxml2ly}, these regression tests
223 can be used to test any MusicXML implementation.
225 The MusicXML regression tests are found at
226 @file{input/regression/musicxml/}.
228 The output resulting from running these tests
229 through @samp{muscxml2ly} followed by @samp{lilypond} is
230 available in the LilyPond documentation:
233 @uref{http://lilypond.org/doc/latest/input/regression/musicxml/collated-files}