[dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Neil Horman]

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.
> 
> 
> 
>