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

On 30/11/11 14:59, Markus Mohrhard wrote:
> after we enabled subsequenttests in sc again we have now a lot of
> failing tests. Instead of debugging the java based tests I plan to
> rewrite them in c++ and fix them during that.
>
> The test itself is a bit ridiculous 

so it is a faithful reproduction of the qadevOOo tests :)

> - having test files instead of code that fills the cells make it
> easier to use the test data outside of the test ( e.g. debugging a
> problem, having a testdocument with known result for some actions)

hmm... am somewhat unsure about this: the ODF import uses the UNO API to
a large extent, so it could be possible that the test breaks because the
API used by the import is borked, before you get to the actual test of
that same API that would point out directly the failing method (which is
much easier to debug than a somehow wrong import).

> - only a little bit of code needed for a new test, most code is shared
> with our in-build tests

that is of course an advantage of your approach.

> - porting old tests is straightforward
> - does not need an installation
> - needs much more makefile lines than the old tests ( there might be a
> solution to this )

seems makefile is so big that it didn't fit in the mail ;)

i am somewhat unsure if the current approach of having essentially a
custom makefile for each test is the right way to go; sure you don't
need a running office, but instead every test makefile needs careful
maintenance so all the dependencies are mentioned (which are not always
obvious), and custom rdbs and stuff.

now if only we could run soffice from the solver directly...

> The concept needs still a lot of love and is only intended as starting
> point. I hope that this makes debugging subsequenttests easier and
> writing new tests as easy as writing in-build tests.
>
> Do you have comments or suggestions?

i second Stephan's request about not using qa/unoapi: that has a very
specific meaning firmly tied to the qadevOOo mess.

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

regards,
 michael