Re: [Denemo-devel] Testsuite, step 3

[Richard Shann]

I get this:

Starting program: /home/rshann/local/bin/denemo -n -a "(d-Critical \"Critical 
error\")(d-Quit)"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Denemo - MESSAGE : Loading preference file: /home/rshann/.denemo-1.1.1/denemorc
Denemo - MESSAGE : Denemo version 1.1.1
Denemo - MESSAGE : Loaded keymap 
/home/rshann/git-denemo/denemo/actions/Default.commands
Arranger Profile
Denemo - CRITICAL: Critical error
[Inferior 1 (process 12323) exited normally]
(gdb) 

Richard


On Tue, 2013-12-17 at 16:54 +0100, Éloi Rivard wrote:
> Well I might have an idea. I have set the level of scheme errors from
> Warning to Critical. Maybe in your configuration Critical warnings are
> fatal (i.e. kills the program).
> 
> 
> If you run denemo -n -a "(d-Critical \"Critical error\")(d-Quit)",
> does your program ends normally or fail ?
> 
> 
> 
> 2013/12/17 Richard Shann <address@hidden>
>         On Tue, 2013-12-17 at 14:50 +0100, Éloi Rivard wrote:
>         > Hi,
>         >
>         > I have some good news, I added a test named "coverage" that
>         reads
>         > Defaults.commands and tests every command it finds in it
>         (1012 tests
>         > for the moment). For each command the tests checks if
>         > coverage-data/COMMAND.scm exists, and execute it if it
>         exists. Else it
>         > simply launch denemo with '-a "(d-COMMAND)(d-Quit)".
>         >
>         >
>         > This is still a very weak test, since there is no argument
>         passed to
>         > the commands, and since that results are not checked. But at
>         least it
>         > can check for some segfaults. This test double our test
>         coverage (we
>         > were around 10% now, we are at 20%). The coverage test is
>         very long.
>         >
>         >
>         > To keep things clean, a test should be created every time a
>         command is
>         > created (in tests/coverage-data/COMMAND.scm). Tests should
>         be as
>         > simple as possible, and provoke failure when the result
>         obtained is
>         > not the one expected.
>         >
>         >
>         > More generally, each implemented feature and each fixed bug
>         should
>         > have its own test.
>         >
>         >
>         >
>         > Next step is to also test builtin functions declared in
>         > scheme-identifiers.c and find a way to run GUI tests, and
>         add some
>         > unit tests for often used functions.
>         
>         
>         This is excellent stuff. A couple of points - one is there is
>         a
>         deliberate scheme error generated in the score-checking
>         command (a bad
>         idea of course). And, I have had Denemo terminate recently as
>         a result
>         of scheme errors, which it never did with the old handler. I
>         haven't
>         been able to figure out the conditions when this happens, but,
>         of
>         course, it makes it very difficult to find this out.
>         
>         Richard
>         
>         
>         
> 
> 
> 
> -- 
> Éloi Rivard - address@hidden
>         
> « On perd plus à être indécis qu'à se tromper. »
>