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
