From: Neil Horman <nhorman@tuxdriver.com>
To: "Doherty, Declan" <declan.doherty@intel.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
Date: Wed, 3 Aug 2016 08:51:06 -0400 [thread overview]
Message-ID: <20160803125106.GC3603@hmsreliant.think-freely.org> (raw)
In-Reply-To: <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com>
On Wed, Aug 03, 2016 at 09:57:39AM +0000, Doherty, Declan wrote:
>
>
> > -----Original Message-----
> ...
> > You are not advocating but the unit test must be written in C++.
> > I don't think it is a good idea to force people to write and maintain the tests
> > in a different language than the code it tests.
>
> I know where you are coming from on this point, and I general would agree if
> it were not for the advantages you get from C++ test framework. Having worked with
> multiple C and C++ frameworks, I've found that one of the biggest advantages of the
> C++ frameworks is the amount of boilerplate code they can save you from writing. Also
> nearly all of C frameworks I've used make use macros to the point that they look more like
> objective C than C. In general I feel that even if the test code is written in C++ the code itself
> should be simple enough that someone with even a passing knowledge of C++ could easily
> understand the intent of the test code.
>
> > > Some of the major advantages of google test that I see over continuing to use
> > the
> > > current test include giving a consist feel to all tests, a powerful test
> > > execution framework which allow individual test suites or tests to be specified
> > > from the command line, support for a standard xunit output which can be
> > integrated
> > > into a continuous build systems, and a very powerful mocking library
> > > which allows much more control over testing failure conditions.
> >
> > It would be interesting to better describe in details what is missing currently
> > and what such a framework can bring.
> > (I agree there is a huge room for improvements on unit tests)
>
> Some of the things I've come across include:
> No standard output format to integrated with continuous regression systems
> No ability to specify specific unit tests or groups of tests to run from the command line
> No standard set of test assertions used across the test suites.
> No standard setup and teardown functions across test suites, state from previous test
> suite can break current
> Requirement to use a python script to orchestrate test runs.
> No support for mocking functionality.
>
I think libcheck:
https://libcheck.github.io/check/
Ticks most of those boxes, or can have the missing functionality added fairly
easily.
> I know that none of the above couldn't be fixed in our current test application, but I would
> question if it is effort worthwhile when we take an off the shelf framework, which does all
> those things and a whole lot more, which has been test and used in a huge variety of
> projects.
>
> I certainly willing to look at other frameworks both C and C++ but I yet to find a C framework
> which come close to the usability and flexibility of the popular C++ ones.
>
>
>
>
next prev parent reply other threads:[~2016-08-03 12:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 20:37 Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 1/4] mk: Add support for C++ compilation Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 2/4] examples: add c++ example application Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout Declan Doherty
2016-08-03 11:25 ` Neil Horman
2016-08-02 20:37 ` [dpdk-dev] [RFC 4/4] app/test-gtest: example google test application Declan Doherty
2016-08-02 21:52 ` [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thomas Monjalon
2016-08-03 9:16 ` Remy Horton
2016-08-03 9:57 ` Doherty, Declan
2016-08-03 12:51 ` Neil Horman [this message]
2016-08-03 20:46 ` Ming Zhao
2016-08-04 19:47 ` Jim Murphy
2016-08-04 19:55 ` Wiles, Keith
2016-08-05 7:42 ` Thomas Monjalon
2016-08-05 7:41 ` Yerden Zhumabekov
2016-08-05 9:11 ` Remy Horton
2016-08-05 12:59 ` Neil Horman
2016-08-05 14:54 ` Remy Horton
2016-08-03 11:31 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160803125106.GC3603@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).