FastSaxSerializer::write ...

David Tardon dtardon at redhat.com
Thu Jan 21 01:13:24 PST 2016


Hi,

On Wed, Jan 20, 2016 at 11:54:41AM -0600, Norbert Thiebaud wrote:
> On Wed, Jan 20, 2016 at 9:37 AM, David Tardon <dtardon at redhat.com> wrote:
> > Hi,
> >
> > On Mon, Jan 18, 2016 at 12:53:07PM +1100, Chris Sherlock wrote:
> >> I think a unit test might be helpful. They are actually quite easy to write - in fact, I wrote a very simple one the other day.
> >>
> >> Have a look on master at vcl/qa/cppunit/font.cxx
> >
> > Note that you don't have to create a whole new CppunitTest every time.
> > You can add new source files to an existing one. You just have to make
> > sure that only one of the sources contains CPPUNIT_PLUGIN_IMPLEMENT(),
> > otherwise you'd get a linker error.
> >
> > Speaking about excessively granular tests: would anyone protest against
> > an Easy Hack to merge the tests in sal module into bigger groups, e.g.,
> > just one test for osl, one for rtl and another one for sal? I.e.,
> > reduction of the number of CppunitTest makefiles from 33 to 3.
> 
> Yeah but in general merging create trouble with parallelism....
> if you have only 3 unit test, then that can use only 3 cores....
> 
> This is particularly important for the larger one later, which
> consistently add long tail to the build, period of 30s to 2 minutes
> where the build is stuck on waiting for one or two tests to finish

I understand that. And I remember that some of the big import/export
tests have been artificially split for that reason (I was among those
who complained about too long running times). But we are not talking
about long running import/export tests here. We are talking about "real"
unit tests, testing a single class--with no heavyweight setup, no UNO
etc. IMHO a reasonable granularity for those is at the level of subdirs.
Possibly even whole modules if there's just a few of them ATM.

D.


More information about the LibreOffice mailing list