atf-c++ vs GoogleTest vs share/mk

Enji Cooper yaneurabeya at
Wed Feb 27 20:53:50 UTC 2019

> On Feb 27, 2019, at 12:42 PM, Alan Somers <asomers at> wrote:
> On Wed, Feb 27, 2019 at 12:46 PM Enji Cooper <yaneurabeya at> wrote:
>>> 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.
> Having $PWD be a disposable tmpdir is convenient,

This is already handled via kyua, just like it is with plain tests (and ATF and TAP tests for that matter).

> but I'm even more concerned about what happens if a googletest segfaults.  In that case,
> its cleanup routines won't run.  That could potentially be
> catastrophic for the entire test run if the test program does
> something like alter network configuration.  Or do you have a plan for
> this?

I will look into how Googletest currently handles segfaults, etc, and raise that as a point of concern with the upstream project if need be, as I don’t know how exactly this is handled in exceptional cases.


More information about the freebsd-testing mailing list