[scribus] Code Testing
scribus at babel.homelinux.net
Wed Feb 6 00:51:19 UTC 2013
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
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
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
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
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.
More information about the scribus