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

["Ming Zhao(赵明)" <mzhao@luminatewireless.com>]

googletest is a very nice test framework and we use it very
extensively in our company(Luminate Wireless), together with gmock.

I understand the resistance from the maintainers that are concerned
about introducing a C++ dependency to a pure C code base. The approach
we take doesn't require any change to the dpdk core, instead we just
use things like a mock PMD(through gmock framework) to allow mocking
the RX/TX code path, disabling huge page usage in test so that the
test can be easily launched without worrying about huge page
collision, etc.

Personally I highly recommend using googletest plus some basic test
cases, which removes a lot of boilerplate and let the developers focus
the test itself.

On Wed, Aug 3, 2016 at 2:57 AM, Doherty, Declan
<declan.doherty@intel.com> 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 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.
>
>
>