atf-c++ vs GoogleTest vs share/mk

Enji Cooper yaneurabeya at
Wed Feb 27 19:46:15 UTC 2019

> On Feb 27, 2019, at 9:59 AM, Alan Somers <asomers at> wrote:
> So it turns out to be impossible to use GoogleMock with atf-c++.  The
> problem is that atf-c++'s only way to report a test failure is
> ATF_FAIL, which immediately terminates the program on failure.  That
> conflicts with the way that GoogleMock uses pthreads, which is to
> report a failure while a pthread mutex is locked.  atf-c++ has many
> other shortcomings, too.  It lacks the ATF_CHECK_* macros, and its
> syntax is surprisingly inconsistent with atf-c’s.

Yes, I’ve brought that up before in the past. This is part of the reason why I want to abandon/kill off atf-c++ in favor of something more functionally complete, i.e., googletest

> So I tried writing a C++ program that uses atf-c instead.  But the
> Makefiles in share/mk make that a frustrating proposition.  They don't
> want C++ programs to link to atf-c, and they don't want atf-c programs
> to be built in C++ mode.

Well… yeah. This makes sense.

> Googletest would probably work fine, but I would sorely miss ATF's
> test case isolation features.

In what ways? Using plain tests builds in some level of isolation, but it’s not perfect, and this is the direction I’m taking Googletest for a first iteration.

> So what should I do?  Should I fix atf-c++?  That would entail
> basically copying over everything from atf-c, which would be a lot of
> work.  Or should I hack to allow C++ programs to use
> atf-c?  That would be ugly, but easier.  Or should I just switch to
> Googletest, and live with its fragile cleanup handlers?

Using Googletest with Googlemock is the way that I intend to have things work. Adding ATF into the mix as another layer seems like the ultimate path to pain, since ATF’s libraries require full stack management in order to do things like handle sandboxing, etc, and Googlemock does some clever things with C++ that seems like they would conflict with ATF’s goals.

I’ll work on closing out the first iteration of by the end of the week and work on getting the code committed to ^/head. In parallel, I’ll focus on adding googletest driver support to kyua (I have part of it done, but there are still some missing pieces around test listing and results parsing), which is the next required phase in order to make googletest function more flexibly with kyua.


PS I appreciate the reminder about documenting my work and my goals on the wiki. I’ll do that now.

More information about the freebsd-testing mailing list