The khtmltests/regression CVS directory contains 3 subdirs: tests, baseline and output. Within tests there are several .html and .js files that contain test cases. These test cases do not have much of a meaning for themselves - they are there to be checked by khtml/test_regression. So if you fixed a bug or implemented a new feature in khtml or kjs, do in khtml('s builddir):
make test_regression && ./test_regression $SRCDIR/khtmltests/regression

This will output a lot of debug output, so I'm usually adding a "2>/dev/null | tee log" behind the command line. This only outputs lines with PASS and FAIL. Currently we have 20 failing tests in there, so don't worry too much if you changed something in khtml and 12 javasript test cases fail :)

test_regression will check the dom and the renderer tree against what is in baseline, so if you change a test case, it will happen, that test_regression will output FAIL for that test case (like after Koos's commit). In that case, it creates the new version in the output subdir. So you can diff against the baseline yourself and see if everything is fine. The commit above adds actually 3 failing tests, so this is no good regression test. The regression database is supposed to be all passes at all times (we'll sort out the currently failing ones soon - I may hope).

But in general we're in big lack of good and working test cases. Actually everything that works fine with current CVS should be documented as test case. So that when you fix something that does not work, you see if you broke something that worked before.

So at least for everything that you fixed from now on, you should supply a test case for - if it can be tested at all.

This brings me to what can be tested currently:

We can test .js just fine as the scripting language is build in. There is a little shell.js that offers the function shouldBe, that can be used to check assertions. Actually thanks to the mozilla test suite we've got some 1000 javascript test files that contain each tons of tests.

We can also test html parser in comparing resulting DOM tree. This can also be used to test ecma manipulations. To check the DOM tree is of course a lot more fragile than testing assertions, so checks that break with a fix in the HTML parser have to be double checked if the result is still what is expected (you'll need IE for that ;-).

An even more fragile, but also very useful test is the check for the renderer tree. We can check through this if the renderer tree is similiar to what it was before. As test_regression sets the environment very strictly in using everywhere the same screen resolution, window size, widget style, fonts, etc. this is something that can be used to test against several breakages. Of course we can't test with this the actual painting and we can't really test behavior in selection, mouse hovering, etc.

To check the painting, I'm already having plans to actually compare images, that must be fun and for the other stuff we might add special hooks, so this is just the beginning. My hope is that many more can write good test cases than those that can actually fix bugs. But fixing bugs (and merging other's code in :) is much easier if you've got a collection of test cases that show when something's broken.

And as soon as this test suite stabilizes and is failure free, I'm planning to run it per cron job, so that you get fresh feedback.

The Rosegarden team are pleased to announce the release of Rosegarden-4 0.9.5, an audio and MIDI sequencer and score editor for Linux. To download the source package, go to the homepage at

http://www.all-day-breakfast.com/rosegarden/

This release contains a host of new features and improvements over the previous release, and is nearly feature complete for 1.0.

Features include:

• Score, piano-roll, event list and track overview editors
• MIDI and audio playback and recording using JACK
• Audio plugin support using LADSPA
• Score interpretation of performance MIDI data
• MIDI file I/O, Csound and Lilypond export
• Shareable device (.rgd) files to ease MIDI portability
• Translations into Russian, Spanish, German, French and Welsh

New features since 0.9.1 include:

• Better sequencer comms layer for much more robust MIDI sequencing
• Control rulers for editing velocity and control events
• Controller management for MIDI devices
• Event list editor with some actual editing capabilities
• Event filter on current selection
• Classification of audio plugins using liblrdf
• Percussion and variations support in bank management
• Import Studio from File
• Markers
• File merging for all file types
• Notation rendering using real scalable fonts (one supplied)
• Multi-page notation rendering with panner
• Much better score printing
• Print Preview
• Segment colouring
• Configurable metronome
• Better Lilypond export
• MusicXML export that works, though it's still pretty basic
• Can now drag notes around in notation view
• Several new .rgd device files
• Better handling of MIDI devices that come and go
• Much improved audio scheduling infrastructure
• Ability to drag-and-drop audio files onto segment canvas
• Many optimisations throughout