]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/contributor/regressions.itexi
Doc: CG: updates to Bug Squad.
[lilypond.git] / Documentation / contributor / regressions.itexi
1 @c -*- coding: utf-8; mode: texinfo; -*-
2 @node Regression tests
3 @chapter Regression tests
4
5 @menu
6 * Introduction to regression tests::
7 * Precompiled regression tests::
8 * Compiling regression tests::
9 * Identifying code regressions::
10 * Memory and coverage tests::
11 * MusicXML tests::
12 @end menu
13
14
15 @node Introduction to regression tests
16 @section Introduction to regression tests
17
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.
22
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.
27
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.
38
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
42 system.
43
44
45 @node Precompiled regression tests
46 @section Precompiled regression tests
47
48 @subheading Regression test output
49
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
53 version.
54
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.
58
59 The latest stable version of the regtests is found at:
60
61 @example
62 @uref{http://lilypond.org/doc/stable/input/regression/collated-files.html}
63 @end example
64
65 The latest development version of the regtests is found at:
66
67 @example
68 @uref{http://lilypond.org/doc/latest/input/regression/collated-files.html}
69 @end example
70
71
72 @subheading Regression test comparison
73
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:
78
79 @example
80 @uref{http://lilypond.org/test/}
81 @end example
82
83 Checking these pages is a very important task for the LilyPond project.
84 You are invited to report anything that looks broken, or any case
85 where the output quality is not on par with the previous release,
86 as described in @rweb{Bug reports}.
87
88 @subheading What to look for
89
90 The test comparison shows all of the changes that occurred between
91 the current release and the prior release.  Each test that has a
92 significant difference in output is displayed, with the old
93 version on the left and the new version on the right.
94
95 Regression tests whose output is the same for both versions are
96 not shown in the test comparison.
97
98 @itemize
99 @item
100 Images: green blurs in the new version show the approximate
101 location of elements in the old version.
102
103 There are often minor adjustments in spacing which do not indicate
104 any problem.
105
106 @item
107 Log files: show the difference in command-line output.
108
109 The main thing to examine are any changes in page counts -- if a
110 file used to fit on 1 page but now requires 4 or 5 pages,
111 something is suspicious!
112
113 @item
114 Profile files: give information about
115 TODO?  I don't know what they're for.
116
117 @end itemize
118
119 @warning{
120 The automatic comparison of the regtests checks the LilyPond
121 bounding boxes.  This means that Ghostscript changes and changes
122 in lyrics or text are not found.
123 }
124
125 @node Compiling regression tests
126 @section Compiling regression tests
127
128 Developers may wish to see the output of the complete regression
129 test suite for the current version of the source repository
130 between releases.  Current source code is available; see
131 @ref{Working with source code}.  Then you will need
132 to build the LilyPond binary; see @ref{Compiling LilyPond}.
133
134 Uninstalling the previous LilyPond version is not necessary, nor is
135 running @code{make install}, since the tests will automatically be
136 compiled with the LilyPond binary you have just built in your source
137 directory.
138
139 From this point, the regtests are compiled with:
140
141 @example
142 make test
143 @end example
144
145 If you have a multi-core machine you may want to use the @option{-j}
146 option and @var{CPU_COUT} variable, as
147 described in @ref{Saving time with CPU_COUNT}.
148 For a quad-core processor the complete command would be:
149
150 @example
151 make -j5 CPU_COUNT=5 test
152 @end example
153
154 The regtest output will then be available in
155 @file{input/@/regression/@/out@/-test}.
156 @file{input/@/regression/@/out@/-test/@/collated@/-examples@/.html}
157 contains a listing of all the regression tests that were run,
158 but none of the images are included.  Individual images are
159 also available in this directory.
160
161 The primary use of @samp{make@tie{}test} is to verify that the
162 regression tests all run without error.  The regression test
163 page that is part of the documentation is created only when the
164 documentation is built, as described in @ref{Generating documentation}.
165 Note that building the documentation requires more installed components
166 than building the source code, as described in
167 @ref{Requirements for building documentation}.
168
169
170 @node Identifying code regressions
171 @section Identifying code regressions
172
173 Before modified code is committed to master, a regression test
174 comparison must be completed to ensure that the changes have
175 not caused problems with previously working code.  The comparison
176 is made automatically upon compiling the regression test suite
177 twice.
178
179 Before making changes, a baseline should be established by running:
180
181 @example
182 make test-baseline
183 @end example
184
185 After making the changes, the code should be checked by running:
186
187 @example
188 make check
189 @end example
190
191 After @samp{make@tie{}check} is complete, a regression test comparison
192 will be available at @file{out/@/test@/-results/@/index@/.html}.
193 For each regression test that differs between the baseline and the
194 changed code, a regression test entry will displayed.  Ideally, the
195 only changes would be the changes that you were working on.  If
196 regressions are introduced, they must be fixed before committing the
197 code.
198
199 @warning{
200 The special regression test @file{test@/-output@/-distance@/.ly} will always
201 show up as a regression.  This test changes each time it is run, and
202 serves to verify that the regression tests have, in fact, run.}
203
204 Once @samp{make@tie{}test-baseline} and @samp{make@tie{}check} have been
205 run, the files that differ between @samp{test-baseline} and @samp{check}
206 can be repeatedly examined by doing:
207
208 @example
209 make test-redo
210 @end example
211
212 This updates the regression list at @file{out/@/test@/-results/@/index@/.html}.
213 It does @emph{not} redo @file{test@/-output@/-distance@/.ly}.
214
215 When all regressions have been resolved, the output list will be empty.
216
217 Once all regressions have been resolved, a final check should be completed
218 by running:
219
220 @example
221 make test-clean
222 make check
223 @end example
224
225 This cleans the results of the previous @samp{make@tie{}check}, then does the
226 automatic regression comparison again.  
227
228
229 @node Memory and coverage tests
230 @section Memory and coverage tests
231
232 In addition to the graphical output of the regression tests, it is
233 possible to test memory usage and to determine how much of the source
234 code has been exercised by the tests.
235
236 @subheading Memory usage
237
238 For tracking memory usage as part of this test, you will need
239 GUILE CVS; especially the following patch:
240 @uref{http://www.lilypond.org/vc/old/gub.darcs/patches/guile-1.9-gcstats.patch}.
241
242 @subheading Code coverage
243
244 For checking the coverage of the test suite, do the following
245
246 @example
247 ./scripts/auxiliar/build-coverage.sh
248 @emph{# uncovered files, least covered first}
249 ./scripts/auxiliar/coverage.py  --summary out-cov/*.cc
250 @emph{# consecutive uncovered lines, longest first}
251 ./scripts/auxiliar/coverage.py  --uncovered out-cov/*.cc
252 @end example
253
254
255 @node MusicXML tests
256 @section MusicXML tests
257
258
259 LilyPond comes with a complete set of regtests for the
260 @uref{http://www.musicxml.org/,MusicXML} language.  Originally
261 developed to test @samp{musicxml2ly}, these regression tests
262 can be used to test any MusicXML implementation.
263
264 The MusicXML regression tests are found at
265 @file{input/@/regression/@/musicxml/}.
266
267 The output resulting from running these tests
268 through @samp{muscxml2ly} followed by @samp{lilypond} is
269 available in the LilyPond documentation:
270
271 @example
272 @uref{http://lilypond.org/doc/latest/input/regression/musicxml/collated-files}
273 @end example
274