Subject: Re: Unit test suite for c-ares

Re: Unit test suite for c-ares

From: Jakub Hrozek <jhrozek_at_redhat.com>
Date: Fri, 9 Oct 2015 15:04:24 +0200

On Fri, Oct 09, 2015 at 01:36:20PM +0100, David Drysdale wrote:
> On Fri, Oct 9, 2015 at 12:22 PM, Jakub Hrozek <jhrozek_at_redhat.com> wrote:
> > On Fri, Oct 09, 2015 at 11:14:30AM +0100, David Drysdale wrote:
> >> Hi folks,
> >>
> >> I've made a start on a unit test suite for c-ares, and I'd be
> >> interested in any feedback.
> >>
> >> The changes so far are in a branch at
> >> https://github.com/daviddrysdale/c-ares/commits/test, with some key
> >> points being:
> >> - The tests are in C++11 (mostly so I can use gTest/gMock, using a
> >> local copy of 1.7.0), which needed some extra autoconf macros.
> >> - However, I've deliberately not joined up test/configure.ac to the
> >> main configure.ac, so users of the library need not be blocked by a
> >> missing C++ compiler.
> >> - I've added the ability to inject a user-specified malloc/free, so
> >> that allocation failures can be tested.
> >> - I've also added a Travis config to get automatic builds on at least
> >> Linux/OSX happening: https://travis-ci.org/daviddrysdale/c-ares
> >> - I've also set up an initial coveralls.io page to track code
> >> coverage from the Travis builds:
> >> https://coveralls.io/github/daviddrysdale/c-ares
> >>
> >> The test/README.md file also has some description of the different
> >> types of test that are possible (although there might only be a couple
> >> of examples of each so far).
> >>
> >> Thoughts? Useful?
> >
> > Unit tests are always useful and this is a heap of work, very well done!
> >
> > While I realize the choice of unit test framework is totally subjective,
> > have you considered something in pure C, like cmocka?:
> > https://cmocka.org/
>
> I didn't really consider alternatives to gTest/gMock I'm afraid -- I'm pretty
> familiar with them, and I like being able to use C++ features (like RAII and
> the STL).

Fair enough, I think even for a pure C project like c-ares this is OK as
long as the runtime doesn't depend on C++

>
> > In addition, I was considering using socket_wrapper and running a real DNS
> > server in test environment. We use something similar for SSSD tests
> > where we run an OpenLDAP server during test...but it looks like your
> > tests already run a mock server?
>
> Yeah, given that c-ares effectively allows dependency injection of the
> server port I haven't yet found it necessary to do more invasive things
> like wrapping sockets. I did add the ability to do injection of malloc/free,
> which seemed straightforward enough not to consider anything more
> clever (like library preloading).
>
> cwrap & socket_wrapper do look very interesting though;

In the spirit of full disclosure I should have mentioned earlier I'm
involved in development of both cmocka and cwrap.

> I've idly wondered
> about doing similar things with Linux namespaces, but that wouldn't be
> very portable.

Hmm, could you elaborate, please? What were you envisioning that
systemd-nspawn doesn't do? (Maybe we're getting off-topic for the
c-ares list so feel free to reply with a private mail..)

> Do you know how portable the preloading approach is?
> (E.g. would it work if I ever got a Windows build of the test suite running?)

So far we've added support for UNIX-like platforms only - Linux
obviously, *BSD, OS-X, Solaris, ...
We haven't tried windows and I don't know how would preloading work
there, sorry.

> And does it turn out to be brittle across library/environment changes etc?

That hasn't been my experience so far. The initial platform support
might be a PITA, but once the tests are running, they are pretty stable.

Thanks again for the unit tests!
Received on 2015-10-09