Branch 'feature/gbuild_testtools' - review request

[Stephan Bergmann]

On 05/17/2012 11:43 PM, David Ostrovsky wrote:
> source/bridgetest/* is up and running now (except pyuno).
> The creation of some batch files is skipped, because they wasn't used
> anyway.

Historically, testtools only created test scripts that were not executed 
during build.  Later on, the most fundamental of those test scripts 
(bridgetest_inprocess: run C++ test implementation in a single process) 
was modified to instead be run during build.

However, the other test scripts (bridgetest_inprocess_java: run Java 
test implementation in a single process; bridgetest_server: run C++ test 
implementation against additional bridgetest_client process; 
bridgetest_javaserver: run Java test implementation against additional 
bridgetest_client process) are still useful for manual testing, and I 
occasionally still use them.  I guess it is fine to leave them alone for 
now, and I can see to get them up and running again (maybe even 
automatically during the build) later, after gbuild_testtools is 
integrated into master.

> The single uno test is implemented in CustomTarget_uno_test.mk
> and marked with .PHONY to run every time.

Logically, it should be treated like a CppunitTest_*.mk, bound to the 
"unitcheck" target.

> source/bridgetest/pyuno: i'm not sure if we need it. I guess the python
> test is not executing during
> dmake build now.

Would apparently need "cd testtools/bridgetest/pyuno && make runtest" 
from within "make cmd cmd=bash" these days.  However, that fails for me 
on master, so probably rather rotten already.  So, another potential 
candidate for "ignore for now and fix later."

Yet more stuff is in testtools/source/{performance,servicetests}/, 
currently not included in testtools/prj/build.lst and thus of likely 
dubious quality.  Would need to have a look at those as well, whether 
they're worth resurrecting at all.

And, finally, I noticed that testtools/source/bridgetest/makefile.mk 
used to call cppumaker (on the bridgetest.idl stuff) without any -C or 
-L switches (i.e., in "bootstrap" mode), whereas you now call it with -L 
(i.e., in "normal" mode, cf. gb_*_use_internal_api vs. 
gb_*_use_internal_bootstrap_api), but I doubt that is a problem (and am 
not sure the original decision to use "bootstrap" mode was actually a 
conscious one, anyway).

Stephan