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

Wiles, Keith keith.wiles at intel.com
Thu Aug 4 21:55:55 CEST 2016


> On Aug 4, 2016, at 2:47 PM, Jim Murphy <jmurphy at arista.com> wrote:
> 
> Hi,
> 
> We are looking at using our existing test environment for our DPDK
> applications that will run on our build servers. Hughpages therefore is an
> issue. What is involved in running DPDK without huge pages?

Command line option  —no-huge should work. Note two dashs in front.

> 
> Thanks,
> 
> Jim
> 
> 
> On Wed, Aug 3, 2016 at 1:46 PM, Ming Zhao(赵明) <mzhao at luminatewireless.com>
> wrote:
> 
>> 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 at 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.
>>> 
>>> 
>>> 
>> 



More information about the dev mailing list