From: "Wiles, Keith" <keith.wiles@intel.com>
To: Jim Murphy <jmurphy@arista.com>
Cc: "Ming Zhao(赵明)" <mzhao@luminatewireless.com>,
"Doherty, Declan" <declan.doherty@intel.com>,
"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: Thu, 4 Aug 2016 19:55:55 +0000 [thread overview]
Message-ID: <CAE52828-EE15-41B3-BCE0-55A1274F2322@intel.com> (raw)
In-Reply-To: <CAJC5fi0wZzxKcEovdeqFYyMmG-UT3FNkMC935YtZb-eRS+TzVA@mail.gmail.com>
> On Aug 4, 2016, at 2:47 PM, Jim Murphy <jmurphy@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@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@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.
>>>
>>>
>>>
>>
next prev parent reply other threads:[~2016-08-04 19:55 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
2016-08-03 20:46 ` Ming Zhao
2016-08-04 19:47 ` Jim Murphy
2016-08-04 19:55 ` Wiles, Keith [this message]
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=CAE52828-EE15-41B3-BCE0-55A1274F2322@intel.com \
--to=keith.wiles@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=jmurphy@arista.com \
--cc=mzhao@luminatewireless.com \
--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).