Apache OpenOffice (AOO) Bugzilla – Issue 86525
In-tree, Unit-testing ...
Last modified: 2017-05-20 11:27:44 UTC
Hi guys, I attach our unit testing work; the punch-line is that, during the build you can execute things like: +void Test::createDocument() +{ + ScDocument *doc = createSimpleDoc(); + + double val = 1; + doc->SetValue (0, 0, 0, val); + doc->SetValue (0, 1, 0, val); + doc->SetString (0, 2, 0, rtl::OUString::createFromAscii ("=SUM(A1:A2)")); + doc->CalcAll(); + double result; + doc->GetValue (0, 2, 0, result); + fprintf (stderr, "one plus one = %g\n", result); + CPPUNIT_ASSERT_MESSAGE ("calculation failed", result == 2.0); + + delete doc; +} without having to have a live install. Of course - there are several problems / issues needing input / advice: * we need regcomp earlier, eg. for 'stoc' to register it's components. That means we need to fiddle with cpputools, pushing it down and even into (?) cppuhelper (eg.) ? Failing that we need to add more build.lst dependencies. Currently we miss critical unit-<module>.rdb files in the solver because of this. * [ as an aside we create one unit-*.rdb file per module to avoid races and collate them before running the test ]. * we need input from the comphelper owner: is it ok to whack a somewhat esoteric 'Setup.xcu' file and 'configmgrrc' in your module - and this new libunitbootstrap library ? * we need testing on Win32 - sad but true, I can't easily build / run there, and there are bound to be odd bootstrapping / URL type issues around the place. * there is some ugly cut/paste of the perl goodness from the installer to get the regcomp calls doing what is expected of them: ideally a little re-factoring advice from a build-engineer would be good. Anyhow - if we can fix the first issue, this can be made a conditional compilation option on Unix, and at least get the infrastructure into CVS; but assistance from Sun much appreciated here.
Created attachment 51757 [details] sample calc unit test
Created attachment 51758 [details] bootstrapping magic
Created attachment 51759 [details] changes to deliver to register components
Assigning this to SB, he seems a more appropriate owner for this kind of stuff. As for comphelper, where I am perhaps closest to being an "owner": Well, I'd probably prefer having a dedicated module for the unit test infrastructure, instead of putting it into comphelper. However, I know there are different opinions on such an inflation of module numbers, so I'm not too strict about it. From a quick look into the deliver-patch - if I understand it right, you changed it to always re-register UNO components which have been changed - which sounds questionable and unnecessarily expensive, IMO. Personally, I'd prefer this being an explicit thing, to be done when I actually embark upon running a unit test. But that might be only me.
> fst > From a quick look into the deliver-patch - if I understand it right, you > changed it to always re-register UNO components which have been changed Not quite - I changed it to register UNO components as they are installed into the solver [ at least into an RDB file for that module ]; this was never the case in the past, registration occuring only as an install-set is produced. > Which sounds questionable and unnecessarily expensive, IMO. > Personally, I'd prefer this being an explicit thing, to be done > when I actually embark upon running a unit test. But that might be only me. Clearly scanning all .so files to build a complete .rdb file each time a unit test is called (ie. per module) adds some N^2 load / relocate / test issue, whereas merging the .rdb files adds only an N^2 in merging simple. rdb files, a rather fast operation in comparison. My request for a decision on merging cpputools/source/registercomponent into cppuhelper, or re-arranging dependencies there is key here though.
Re regcomp: Would it work to make all modules that need regcomp depend on cpputools, or would that cause dependency cycles? If it works, I think that would be the easiest solution. Re comphelper: Would not testshl2 (esp. post issue 86509) instead be a good place for any odd stuff needed during testing? Re deliver: My guts tell me to avoid trickery in deliver. If module M shall deliver unit-M.rdb, I would rather assume to have a rule in some of Ms makefile.mks to build it, and then deliver it normally. Input from Release Engineering appreciated.
@sb: as you said, deliver is not the right place to do such trickery. Much better to create the *.rdb files in the modules and deliver them as file.
sb wrote: > Re regcomp: Would it work to make all modules that need regcomp > depend on cpputools, or would that cause dependency cycles? Possibly - but of course cpputools requires 'offuh' - which looks like it would mean that everything that delivers an UNO component would require offuh - I assume that breaks the encapsulation of the 'udk' piece; does it ? > Re comphelper: Would not testshl2 (esp. post issue 86509) instead be a > good place for any odd stuff needed during testing? Well; yes, and no ;-) that would mean we can't use testshl2 in any of the modules below UNO - eg. sal/ without circular dependencies which doesn't sound optimal. Ultimately, I'm convinced unit testing should be an integral part of our software stack: of course, we can create "yet another module" eg. 'testshl2uno' or something, but a new library in comphelper seemed simpler. > Re deliver: My guts tell me to avoid trickery in deliver. If module M > shall deliver unit-M.rdb, I would rather assume to have a rule in some > of Ms makefile.mks to build it, and then deliver it normally. Sounds like a good suggestion, and hr seems to agree. Of course - the core problem here is maintaining the unit tests in a working state: as such I would suggest that we deliver a single RDB file per-module, and we use this for two purposes: * building install sets * running the unit tests. This should have several nice advantages - in particular faster install set builds; and a simplification of the scp (and moving that into modules) - since we could remove many of the UNO_COMPONENT Styles from there. Of course, first we need closure on the regcomp dependency issues. More advice Stephan ?
- "cpputools requires 'offuh'": that is a ("harmless") mistake that can (and probably should, latest when we move forward with the layering of the build process) be fixed, for example in that offuh is split in two modules, one to create the C++ headers for ukdapi, one to create the C++ headers for offapi; I would ignore the ("harmless") consequences of that mistake for now in the context of this issue - "can't use testshl2 in any of the modules below UNO": that's what I would like to see, anyway (and hope lla will end up with on issue 86509); have plain cppunit as an external module, (minimally) adapt unit tests in low level modules to use plain cppunit instead of testshl2, and reserve the additional functionality of testshl2 for tests in higher level modules (where it is probably needed) - per module rdb for building install sets (in addition to for running the unit tests): might cause problems when (for whatever reason) only some of the services from a module shall end up in a given install set; I would consider this re-use of the per module rdbs as nice to have but not essential for this issue
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assigne to the default "issues@openoffice.apache.org".