[scribus] Code Testing

[Nik Trevallyn-Jones]

Hi All,

My apologies if I am posting this to the wrong forum.
- I checked at the developer forums, but they seemed pretty deserted.

I would like to discuss what form of code testing is used in the 
development of Scribus.

I am a long-time, though irregular, user of Scribus. Over time I have 
recommended, installed and supported Scribus for various users - almost 
always on Linux.

My own observation is that while the 1.3 releases of Scribus were 
generally robust, with very rare crashes, and relatively few severe 
bugs; the 1.4 releases are nowhere near as robust with quite frequent 
crashes.

All of my users who are on some form of the 1.3 release are stable, and 
very happy with the product.
More recently I have upgraded some users to 1.4 - usually at their own 
request.
One site (a volunteer-run library) found Scribus 1.4.0 to be so 
unreliable that they gave up and got a licence of Indesign instead.

I have just upgraded my own machine to 1.4.2 so I can support another 
new user.
And while the crashes I used to experience regularly with 1.4.0 on my 
machine have gone; my user, who is on Windows, experiences at least 1 
crash per day.

Looking through the Scribus source, I have found a single cpp file with 
the word "test" in its name.

So I have some questions:

Q1. Is there a body of unit and/or system tests for Scribus?
Q1a. If so, where are they - and how are they run?
Q1b. If not, how can we proceed to create a body of tests and run them 
regularly (hopefully automatically)?

I am a programmer myself, and realise that writing tests is boring, and 
unglamourous.
However, there are 2 major benefits from having a body of tests that 
cover the majority of the code base:

1. The quality of the product is dramatically increased;
2. The development time is significantly *decreased*;

In short, by investing the time to create tests, then not only will the 
quality and robustness of the resulting code increase, but we will end 
up spending less time developing that higher quality code.

In case the terminology I am using is different to the terminology that 
others use, I am using the term "unit test" to refer to a set of tests 
for a single, isolated C++ class (unit of code) - and in which there 
should be at least 2 tests for each method in the class under test.

And I am using the term "system test" to refer to a single test which 
tests multiple classes in unison ("system test" is also referred to as 
"integration test"), in which there is at least 2 tests for each use 
case being tested.

If the answer to all this is that there are no, few, or not enough 
tests, then I would like to help change that - firstly by helping with 
the decisions on a testing strategy; and then by helping create and/or 
manage the tests in that strategy.

Cheers!
Nik