Hi Damjan, That sounds great!
Regards, Matthias Am 18.07.24 um 05:48 schrieb Damjan Jovanovic:
Hi Over the last month or so, over 88 commits, I've made many improvements to our unit tests, and many related changes, and have now pushed these changes to trunk. They have included the following: - The "complex" tests (usually in <module>/qa/complex) now all only use JUnit to run. JUnit is far more widely known, and uses annotations such as "@Test" and "@Before" / "@After", instead of the older and more error-prone methods used by qadevOO's ComplexTestCase class, such as overriding method names and returning a list of strings naming the methods to test (which had listed a method's name twice, in at least one case I found). This is something that Sun/Oracle began even before OO.o became AOO. - Some of the "unoapi" tests (usually in <module>/qa/unoapi) now also use JUnit to run. Many more could be converted, but what I'd like even better is to eliminate this strange test category (which also uses code from qadevOO/java), and turn all unoapi tests into complex tests. - Many bugs in our test infrastructure have been fixed, including some variable name typos in dmake, use of the hamcrest-core.jar with JUnit, path to OpenOffice executable for the current version has been fixed, . - Some tests that work but weren't being built or run, have been added back, and now do run. - Many code cleanups were made. - Some error messages were made more descriptive. - The "test" module was ported from dmake to gbuild and CppUnit to Google Test. - The typeDetection test (filter/qa/complex/filter/detection/typeDetection) was heavily refactored, and I started rebuilding its document repository (so far, only with a few images and documents). - Stopped unnecessary packaging and delivering of main/connectivity complex tests. - On Windows the dmake launcher needed to unzip the "archive" package format to run the tests. This no longer happens. It uses the "installed" package format like on other platforms. In terms of future developments, maybe we should move the "complex" tests (and eventually "unoapi" tests too) from main/<module>/qa/complex to test/? That way, we would have only 2 types of tests: the module-specific unit tests that run during the build, usually using Google Test, and the "subsequent tests" which need a full OpenOffice to test, and thus run after the build from test/, and can even be run on a different instance of AOO. How do you use these tests? Long ago you could run "subsequenttests" from main/, but that broke due to some gbuild bug. At present a specific module can be tested by running: OOO_SUBSEQUENT_TESTS=1 build inside that module. For now, to test all modules, I made a Python script that loops over all modules and calls that command and captures output. Unfortunately, at least on my Windows setup, I also need this patch: ---snip--- diff --git a/main/test/java/test/src/main/java/org/openoffice/test/OfficeConnection.java b/main/test/java/test/src/main/java/org/openoffice/test/OfficeConnection.java index 30d7636..ea4f97e 100644 --- a/main/test/java/test/src/main/java/org/openoffice/test/OfficeConnection.java +++ b/main/test/java/test/src/main/java/org/openoffice/test/OfficeConnection.java @@ -50,7 +50,8 @@ public final class OfficeConnection { public void setUp() throws Exception { String sofficeArg = Argument.get("soffice"); if (sofficeArg.startsWith("path:")) { - description = "pipe,name=oootest" + UUID.randomUUID(); + //description = "pipe,name=oootest" + UUID.randomUUID(); + description = "socket,host=127.0.0.1,port=2002"; ProcessBuilder pb = new ProcessBuilder( sofficeArg.substring("path:".length()), "-quickstart=no", "-nofirststartwizard", "-norestore", ---snip--- because of a strange bug where Java cannot load our jpipe.dll due to some MSVCRT-related bug. This patch works around it by using sockets instead. (Our tests in test/ always used sockets.) Tests aren't the most exciting thing to develop. But they are important in maintaining code quality, helping to discover bugs and regressions. Some confusing tests were also holding me back from upgrading dmake modules to gbuild. Regards Damjan
smime.p7s
Description: Kryptografische S/MIME-Signatur