Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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@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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.