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


Hey Bjoern,

2012/4/18 Bjoern Michaelsen <bjoern.michaelsen@canonical.com>:
On Wed, Apr 18, 2012 at 09:33:51PM +0200, Lubos Lunak wrote:
 This:

On Monday 16 of April 2012, Markus Mohrhard wrote:
2012/4/16 Lubos Lunak <l.lunak@suse.cz>:
On Monday 16 of April 2012, Michael Meeks wrote:
      Oh - and finally (Lubos) I pushed an item to the ESC agenda to
discuss whether we should be exposing tons of classes and their symbols
in the product, just to make unit tests work :-)

 I assume this is about 69d46dd7a6adfffd71da055bb65108c80d27395f .
...
I was really annoyed by the fact that is was changed without at least
asking and noticing the people who are affected by this change. There
were good reasons to have the old behaviour and I spend some ours
searching for a bug because I had to export a method for ucalc. IMHO
such basic things should not be changed without noticing and
discussing with the people who are directly working in that area.

On a more practical note: I think that can be solved by joining the 14 (!)
toplevel CppunitTests into one test suite containing all the tests. In theory
that would loose use some time because the tests dont execute in parallel, in
practice statically linking the whole sc 14 times is costing waay more.

And I stand by that a test should be able to test internal state. At least when
the "unit" is sc.


We only had one unit test in calc that needed full access to calc
core. I think we had one test for sc, sw and sd called ucalc, uimpress
and swdoc-test whereas all other tests linked dynamically against the
libraries. In my opinion it is ok to have one test that links
statically against the big libraries to prevent exporting all needed
symbols and integrating all test cases needing access to the core into
this unit test.

Regards,
Markus

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.