On 15/12/11 11:34, Stephan Bergmann wrote:
On 12/15/2011 10:58 AM, Tomáš Chvátal wrote:
So unless you can look at one of those traces and tell me that the
build should be stopped because "it is obvious error in the code (not
in the test, the app code) that needs to be fixed" I would want you
Hard to tell without a backtrace.
our new so-called unit tests are not as reliable as i would like:
i have seen this in build from scratch myself, sometimes the hwpfilter
test crashes, and it never happens when building only that module.
i guess the reason is probably that it needs some library loaded via
UNO, and concurrently with the test another process overwrites that
library (have seen exactly that with a test in sw and fixed it), making
the test very unhappy.
the problem i see is that most of our CppUnit test are not really unit
tests but system level tests, and really need most of a full office with
UNO stuff and configuration to run.
figuring out which UNO components are needed to run the test is a real
pain and so of course lots of dependencies are missing.
we wouldn't have this problem if these were subsequenttests; it would
even be possible to run them when rebuilding a single module with
something like "make build && make subsequenttests" (perhaps "make
check" in a module should do that?), just not on the build from scratch.
Context
[Libreoffice] Candidate patch for integration? · Muthu Subramanian K
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.