https://bugs.freedesktop.org/show_bug.cgi?id=48024
--- Comment #8 from DavidO <d.ostrov...@gmx.de> --- (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 -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice