Date: Wed, 27 Feb 2019 13:42:38 -0700 From: Alan Somers <asomers@freebsd.org> To: Enji Cooper <yaneurabeya@gmail.com> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, Ed Maste <emaste@freebsd.org>, Julio Merino <jmmv@freebsd.org>, "Jonathan T. Looney" <jtl@freebsd.org> Subject: Re: atf-c++ vs GoogleTest vs share/mk Message-ID: <CAOtMX2jCi9ZUVdCLVE8kMRcrdwAmSbLPJTmHdhf3pJyyWR=k-A@mail.gmail.com> In-Reply-To: <C9F53820-7817-4FEC-A20C-ACA35819E763@gmail.com> References: <CAOtMX2h_tJHH=mX8wVrMLQNeCsN%2B_D4Jw35KyuiHUcQniNweWg@mail.gmail.com> <C9F53820-7817-4FEC-A20C-ACA35819E763@gmail.com>
index | next in thread | previous in thread | raw e-mail
On Wed, Feb 27, 2019 at 12:46 PM Enji Cooper <yaneurabeya@gmail.com> wrote: > > > > On Feb 27, 2019, at 9:59 AM, Alan Somers <asomers@freebsd.org> 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, 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? > > > 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 atf.test.mk 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 googletest.test.mk 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. Cool. Feel free to add me as a reviewer. > > Thanks, > -Enji > > PS I appreciate the reminder about documenting my work and my goals on the wiki. I’ll do that now.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jCi9ZUVdCLVE8kMRcrdwAmSbLPJTmHdhf3pJyyWR=k-A>