Several of the existing C++ unit tests are run using JUnit. It makes more sense to run these using CppUnit, besides being faster, and more convenient for people who have configured Java out.
I assume that you are referring to the legacy so-called "complex" and "unoapi" tests here, located in */qa/{complex,unoapi} directories within various modules, and based on qadevOOo Java code. They are unfortunate for various reasons (requiring a complete LO installation to run against; unoapi tests being too generic; tests being slow; failing tests are hard to diagnose; occasional spurious failures; etc.; see also <http://wiki.services.openoffice.org/wiki/Test_Cleanup#unoapi_Tests>), but still prove effective in finding regressions (see the Linux-RHEL6-x86_64@14-with-check tinderbox).
Deleted "Easyhack" from summary.
@Noel, Stephan: we can mark this enhancement request as NEW? Or isn't this an enhancement request (or is it already done)? Thanks! Joren
This is still an open issue.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
I would like to look into this issue. Can someone give some pointers? new to this
(In reply to comment #6) > I would like to look into this issue. Can someone give some pointers? new to > this The most obvious approach would be to translate individual so-called "complex" tests (see comment 1) from Java to C++. Those are largely self-contained tests that start and connect against an soffice instance (via Java org.openoffice.test.OfficeConnection; the C++ equivalent is in include/unotest/officeconnection.hxx) and then use remote UNO to trigger the code under test in the running soffice. The test code is typically located in */qa/complex/ directories (e.g., sw/qa/complex/checkColor/CheckChangeColor.java), and often makes use of helper functionality from qadevOOo/runner/util/ (for which there may or may not be C++ equivalents). Both building and running the tests is triggered by */JunitTest_*_complex.mk makefiles (e.g., sw/JunitTeste_sw_complex.mk). In a first approximation, a corresponding CppunitTest would still connect to an soffice process and access it via remote UNO, though in the long run it is of course more desirable to have the code under test small and self-contained enough so that it can run directly in the cppunit process.
(In reply to comment #7) > (In reply to comment #6) > > I would like to look into this issue. Can someone give some pointers? new to > > this > > The most obvious approach would be to translate individual so-called > "complex" tests (see comment 1) from Java to C++. Those are largely > self-contained tests that start and connect against an soffice instance (via > Java org.openoffice.test.OfficeConnection; the C++ equivalent is in > include/unotest/officeconnection.hxx) and then use remote UNO to trigger the > code under test in the running soffice. The test code is typically located > in */qa/complex/ directories (e.g., > sw/qa/complex/checkColor/CheckChangeColor.java), and often makes use of > helper functionality from qadevOOo/runner/util/ (for which there may or may > not be C++ equivalents). Both building and running the tests is triggered > by */JunitTest_*_complex.mk makefiles (e.g., sw/JunitTeste_sw_complex.mk). > > In a first approximation, a corresponding CppunitTest would still connect to > an soffice process and access it via remote UNO, though in the long run it > is of course more desirable to have the code under test small and > self-contained enough so that it can run directly in the cppunit process. To be fair, it can be already done directly with in process python unit tests, see: https://wiki.documentfoundation.org/Development/Python_Unit_Tests
*** This bug has been marked as a duplicate of bug 45904 ***
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillCpp) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]