Re: Copying sc/sd/sw into unittest libs (Re: namespace / typing thrash ...)

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