nthiebaud at gmail.com
Wed Jan 20 09:54:41 PST 2016
On Wed, Jan 20, 2016 at 9:37 AM, David Tardon <dtardon at redhat.com> wrote:
> 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
>From a build wall-time point of view reasonably small and balanced
execution time for tests is important for the overall performances of
the big boxes. (1)
(1) of course too small tests are not good either because then the
set-up tear-down overhead dominate.. which is not good for perf
either. No I do not know the magic optimal value, but it is something
to keep in mind: merging a bunch of test into one is not all positive
More information about the LibreOffice