[Libreoffice] concept for c++ based subsequenttests

[Markus Mohrhard]

Hey,

> Looks very promising.  Just one minor comment, I would move away from the
> "unoapi" name (and corresponding qa/unoapi directory).  The concept of the
> qadevOOo unoapi tests was to use more-or-less generic code to test all the
> interfaces of all the UNO objects exposed by OOo (so that all the objects
> that implemented, say, XPropertySet would get more-or-less the same
> treatment of all the methods comprising XPropertySet).  Do you plan to do
> likewise with your new approach?

No, I did not. IMHO a test should be as simple as possible as long as
it is easily debuggable at the same time. If there is need to test the
XPropertySet interface of a service then write a test and if there is
some similar test code refactor it. I think that this is the better
approach than over-engineering the test framework as done in qadevOOo.

(I'd suggest not to, at least not in the
> excessively generic style of qadevOOo.  It certainly makes sense to factor
> out test code useful in various scenarios, but one main property of test
> code is that it should be simple---so simple that you can trust it is
> testing what you intend it to test, and that a failing test makes it
> glaringly obvious where the failure is.  Something the is completely lacking
> from the qadevOOo concept.)

I totally agree. And I think that this is a huge advantage of this
concept. You can write simple test cases and if they fail you can set
a breakpoint at the suspicous line in the test file and step into the
code.

>
> Your new tests are plain unit tests like the other new sc/qa/unit tests.
>  That they are hooked up to subsequentcheck rather than unitcheck is only to
> not slow down builds, not because they inherently cannot be run during a
> build (like the original qadevOOo based tests that require a complete LO
> installation).  Maybe it would make sense to put them into a sc/qa/extra
> directory?

Good point. I'll do that.

Markus