On Mi, 2011-07-27 at 10:40 +0200, Murray Cumming wrote: > While we are on the subject, is there any particular reason that, when > --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 program? 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 source > anyway, Only for unit testing. Integration tests do not affect the binaries/libraries and therefore are enabled when compiling syncevolution.org 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 run there. > 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 locally). 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 https://bugs.meego.com/show_bug.cgi?id=735 > 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 > correct. 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
