when the component is
integrated into the production code.
The things in the “flower” directory seem like good candidates for broader unit
testing. They seem to change infrequently and they are less complex than the
parsing and engraving components.
—
Dan
_
On 1 Nov 2016 01:03, "Carl Sorensen" wrote:
>
>
>
> The only thing that I can think of for unit testing is to do the
following:
>
> 1) For each file, define a set of regression tests that the file affects.
> The set of regression tests should exercise all known func
s be examining their properties after the function call?
>
>But what about Scheme code?...
The only thing that I can think of for unit testing is to do the following:
1) For each file, define a set of regression tests that the file affects.
The set of regression tests should exercise all
On Sat, 29 Oct 2016 at 20:32 Urs Liska wrote:
>
> That's what I thought, and that's of course a good thing. But would it be
> conceivable to actually start doing unit tests? One should probably not be
> frightened by the issue that we won't be able to apply that backwardly, to
> the existing code
Am 29. Oktober 2016 12:06:20 GMT-07:00, schrieb Carl Sorensen
:
>
>
>On 10/29/16 11:34 AM, "lilypond-devel on behalf of Urs Liska"
>u...@openlilylib.org> wrote:
>
>>Is there any notion (or the potential for a notion) of unit testing in
>>LilyPond&#x
On 10/29/16 11:34 AM, "lilypond-devel on behalf of Urs Liska"
wrote:
>Is there any notion (or the potential for a notion) of unit testing in
>LilyPond's development process?
I think that the regression tests is the closest we get to unit testing.
make test-baseline
make
Is there any notion (or the potential for a notion) of unit testing in
LilyPond's development process?
Urs
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
