From: "Doherty, Declan" <declan.doherty@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "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 09:57:39 +0000 [thread overview]
Message-ID: <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <5511822.hGlaykcsx3@xps13>
> -----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 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 9:57 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 [this message]
2016-08-03 12:51 ` Neil Horman
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=345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com \
--to=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).