Date: Tue, 17 Jan 2017 16:09:21 -0800 From: Craig Rodrigues <rodrigc@freebsd.org> To: "freebsd-testing@freebsd.org" <testing@freebsd.org> Subject: Re: Looking at replacing ATF/Kyua (in a limited fashion) with Google Test/shunit2 Message-ID: <CAG=rPVegLMBhv3hXsabhs_QZ1069HPmPsRS9i2605GZ3qP9izQ@mail.gmail.com> In-Reply-To: <45D23581-C780-4C55-80CF-19A81813D672@gmail.com> References: <45D23581-C780-4C55-80CF-19A81813D672@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 17, 2017 at 3:01 PM, Ngie Cooper (yaneurabeya) <
yaneurabeya@gmail.com> wrote:
> Hello all,
>
> I had an initial discussion with a handful of other test
> stakeholders and due to the number of caveats with ATF/Kyua and a variety
> of issues in contributing back to the ATF/Kyua projects (time on
> maintainer=E2=80=99s end, legal issues, technical issues, etc), I'm serio=
usly
> considering replacing parts of ATF/Kyua with GoogleTest and shunit2. In
> particular, I want to do these things [better]:
I'll provide my perspective on your proposal.
For me, the nice thing about ATF/Kyua was that Julio pushed unit tests to
live along-side the code in FreeBSD,
and provided a consistent structure by which these tests could run and
provide test output.
The fact that he was able to modify the Makefile system to get this working
in FreeBSD *and* NetBSD
is amazing. I never would have had the energy to do that!!
I was hoping that ATF/Kyua would attract interest from projects other than
FreeBSD and NetBSD,
so that there would be an ecosystem of projects that would use this stuff
and drive this forward.
I updated the Mac Homebrew port of Kyua a few times, and also tried to
submit a Debian package
for ATF and Kyua but got stalled there.
Unfortunately, ATF/Kyua never really took off outside of FreeBSD and NetBSD=
.
Also, the implementation details of modern C++ and Lua for Kyua, and shell
script and C for ATF
is a high barrier of entry for people wanting to work on the code and
extend it.
There are enough developers in FreeBSD who could probably pick up the C and
ATF parts.
For the C++ and Lua parts, I think the barrier is quite high, and there are
not that many developers
in the FreeBSD community with the skills or interest to work on that.
I have a selfish perspective in that I like to invest time in libraries and
technologies that
help me get jobs, even in companies that are not FreeBSD.
In my last job at a company making a FreeBSD appliance, I tried to push
adoption of ATF/Kyua
but wasn't able to convince folks to pick it up. The developers gave me
feedback that the ATF/Kyua
documentation didn't give them confidence. It didn't help that I couldn't
point to other projects
outside of FreeBSD/NetBSD using this stuff.
At least for me, I cannot say that ATF/Kyua is a marketable skillset which
opens doors for jobs. :(
Moving forward, if you try to steer towards libraries and technologies that
have active
user communities *even outside of FreeBSD*, that would be nice.
Testing software isn't unique to FreeBSD, and there is a lot of good work
going on in these
other communities.
You mentioned that GoogleTest is actively worked on by Google,
but there at last one non-Google community (LLVM) is using it, and has a
selfish interest to
keep it going. That is one plus in my opinion.
GoogleTest uses a 2-clause BSD license, so that is OK.
GoogleTest requires signing a Contributor License Agreement for people who
want to submit patches upstream to them. That's no different from Kyua.
That's a bit annoying, but maybe something we can live with.
So I have no problem with GoogleTest on those points.
My questions for you are:
(1) GoogleTest is very C++-focused. ATF has API's for C, C++, and
shell.
How successful will you be at testing a pile of C code with a
C++-focused library?
It is technically possible (
https://meekrosoft.wordpress.com/2009/11/09/unit-testing-c-code-with-the-go=
ogletest-framework/
)
but what are the gotchas?
(2) What do we do with existing tests? Do they need to be rewritten to
the GoogleTest API?
Or do we have infrastructure that allows existing ATF tests to run
with Google Test?
(3) If this is adopted, are new tests written in GoogleTest API, or in
the ATF API?
(4) Kyua is the tool currently used for running the tests, and
providing test result output.
Kyua has test-case isolation, and the potential to parallelize the
execution of test-cases.
Are the Kyua features of test-case isolation and parallelization
of test-cases must-haves,
or can we live without them?
Do you want to move away from using Kyua, or modify it to work
with GoogleTest?
If you want to move away from Kyua, how do you want people to run
the GoogleTests and
get the test results?
I have no objection to your proposal. Using a more mainstream testing
framework with a larger user community,
and some momentum to keep things going would be nice.
--
Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG=rPVegLMBhv3hXsabhs_QZ1069HPmPsRS9i2605GZ3qP9izQ>