On 11/30/2011 02:59 PM, Markus Mohrhard wrote:
Do you have comments or suggestions?
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? (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.)
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?
Stephan