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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=99s. > > Yes, I=E2=80=99ve 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 f= unctionally 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=E2=80=A6 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= =E2=80=99s not perfect, and this is the direction I=E2=80=99m taking Google= test 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=E2=80=99s libraries require full stack management in or= der to do things like handle sandboxing, etc, and Googlemock does some clev= er things with C++ that seems like they would conflict with ATF=E2=80=99s g= oals. > > I=E2=80=99ll work on closing out the first iteration of googletest.test.m= k by the end of the week and work on getting the code committed to ^/head. = In parallel, I=E2=80=99ll focus on adding googletest driver support to kyua= (I have part of it done, but there are still some missing pieces around te= st 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 th= e wiki. I=E2=80=99ll do that now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jCi9ZUVdCLVE8kMRcrdwAmSbLPJTmHdhf3pJyyWR=k-A>