[Libreoffice] Proposal: slowcheck -- a new gbuild toplevel target

[Stephan Bergmann]

On 09/19/2011 09:18 PM, Bjoern Michaelsen wrote:
> we now have a good systematic set of test targets with "unitcheck",
> "subsequentcheck" and "check" on master(*). However, we now have so
> many unittests (which is good) that running each and everyone on every
> build slows down the development cycle esp. in sc -- just because they
> taking unittesting serious. Now we:
> a) dont want developers to be punished for writing unittests with slow
>     turnarounds (they might stop writing them)
> b) dont want people to disable all in-build unittests to be run on
>     every compile (because it is far too easy to forget to run them
>     again once before pushing then)
>
> so I am proposing introducing a new target in the build system called
> "slowunitcheck". Those are tests that are technically unittests (need
> no full install), but considered to slow/longrunning to be run on every
> build. Instead those are run along the subsequenttests when running
> "make check" (or alone by running "make slowunitcheck").
>
> Opinions?

I'm somewhat undecided.  While there may be a pragmatic need to exclude 
from constantly building those unit tests that are too slow, offering a 
framework for that might make people choose the easy way out, instead of 
putting work into their slow unit tests to make them fast.  (I do not 
know what makes those sc unit tests slow, so I do not know whether 
lack-of-trying-to-improve applies here.  Just a general concern.  And I 
do know that we already have a framework for fucked up and slow 
subsequenttests, but I would like to get rid of that over time, 
replacing them with true unit tests.)

In general, people may want to consult the literature on what to do 
about slow unit tests, e.g., the section on "Slow Tests" (p. 253ff) in 
Gerard Meszaros' "xUnit Test Patterns: Refactoring Test Code" (A-W, 2007).

-Stephan