On Mi, 2011-07-27 at 10:40 +0200, Murray Cumming wrote:
While we are on the subject, is there any particular reason that,
--enable-unit-tests is used, the tests are installed?
Unit tests, in contrast to integration tests, get embedded in the
libraries. I'm not sure what you mean with "the tests" - the client-test
This is installed intentionally. It is packaged separately for MeeGo so
that QA can run the tests as part of testing the final .rpms.
Presumably the automated testing has to build syncevolution from
Only for unit testing. Integration tests do not affect the
binaries/libraries and therefore are enabled when compiling
and MeeGo packages.
In the nightly testing, the packages are compiled on Ubuntu Lucid. The
integration tests then run on Lucid and Debian Testing (updated manually
from time to time), to cover a wide variety of Linux distros.
so can't it just run the tests in the build directory?
This is where the nightly testing runs them. But they don't have to be
That would make it easier to
1. make the tests run during "make check" only, which is more correct.
2. Always run those tests against only the locally-built syncevolution,
in a private D-Bus session. That makes the testing far easier to do by
more people, more reliably.
I'm afraid that testing simply isn't easy enough to be set up
automatically completely. For the unit tests, yes, to some extend, but
even those depend on a working EDS which (in EDS 2.32) must be set up
manually first. The real tests are interoperability tests which will
always depend on manual setup (register test accounts, set passwords
If you have suggestions for how to make setting up the testing easier
for other developers, then sure, let's discuss it. But I suspect that
even if it was dead easy, contributors would still not run it. I'd
rather focus on having the nightly testing detect problems early,
possibly even before it hits the master branch - see
2. Remove the --enable-unit-tests configure option, so that that main
build does not include the unit-tests code, allowing autotools to
create a separate build with ENABLE_UNIT_TESTS defined, which the builds
will link against. That will almost double the build time, but it seems
I don't like that. I compile with --enable-unit-tests. Doubling my
compile time would be a considerably productivity hit.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.