Re: [SyncEvolution] test/dbus-session.sh ?
On Mi, 2011-07-27 at 11:39 +0200, Murray Cumming wrote:
On Wed, 2011-07-27 at 11:15 +0200, Patrick Ohly wrote:
[snip useful hints]
> > 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.
This could be avoided if the unit tests were not in the same source
files, of course. If necessary they could be next to the source files
with a _test.cpp suffix, though I personally prefer to keep them
separate.
That would, at least in theory, limit testing to public APIs. Done
properly, libsyncevolution.so would not expose internal classes via a
linker script, so those wouldn't be testable by a separate test. In
practice this is not how it is currently done - but it might be one day.
Personally I quite like to embed tests together with the sources because
it lowers the threshold for adding them and I need to deal with less
files.
That would also avoid the risk of the unit tests succeeding just
because
the whole source file was not even part of the build.
True. That's why developers should enable as many features as possible.
And because I don't want to rely on due diligence alone, nightly testing
does it, too, and in more combinations than can be idealistically
expected to be checked by devs before committing.
--
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.