Re: [Libreoffice] concept for c++ based subsequenttests

Hey,

> IMHO the pragmatic solution to this is to run them as subsequentests when
> dependencies are getting ugly. Writing them in sane C++ is of course better
> that using Junit, but nontrivial tests depending on the full product is not a
> big bug IMHO. I think by now pretty much everyone builds a dev-install anyway,
> and linkoo makes this no big overhead.
>
> And from a pragmatic point of view this saves you all the manual dependency
> generation for nontrivial tests which has been shown again and again to be
> fragile and subject to random failure (see recently the sd filters test). Of
> course a plain, well-contained test in sal can should be run in the build, but
> when you need half the office as a dep anyway, I just dont see the point of
> fiddling around with the dep manually.

I think that sc's tests have nearly full dependencies so I did not see
any such problem lately. We use nearly the same makefiles for sc's
filters-test with the same component files and the same dependencies.
But in the end I have no strong opinion here. I need to look into sd's
filters-test sometime to find the missing dependencies.

> > i second Stephan's request about not using qa/unoapi: that has a very
> > specific meaning firmly tied to the qadevOOo mess.
>
> Can we sort this in with the qa/complex test, i.e. tests written with real
> developer intelligence for real world scenarios, maybe?

I will move the qa/complex test into my normal filters-test. They are
doing some similar things and I think that there is no need to have
two concepts that test the same thing.

> > hmmm.... i wonder if it would make sense to have UNO API tests written
> > in Python: that should be much easier on the eyes than boilerplate-heavy
> > C++/Java... and i think there is a need for tests at the UNO API level
> > no matter how many core C++ level tests we have, because there is really
> > no other way to find regressions in that area (nobody tests that
> > manually), might as well try to maximize the productivity...
>
> In general, I agree: Python is the best tool we likely have for this job. OTOH
> it is bound to the UNO API and I wonder if they can be written in a way that
> they do not all die with:
> http://wiki.documentfoundation.org/Development/LibreOffice4 .

Personally I would prefer c++ based uno tests. I know that writing
python code is faster but then we will be again at a point where we
have a language binding between our test code and our tested code.
IMHO tests should be written so that debugging them is as easy as
possible even if it means that writing them might need a bit more
time, but I might be wrong and python based tests are even more easy
to debug.

Markus