From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f180.google.com (mail-yb0-f180.google.com [209.85.213.180]) by dpdk.org (Postfix) with ESMTP id 47F1D2BF6 for ; Thu, 4 Aug 2016 21:47:52 +0200 (CEST) Received: by mail-yb0-f180.google.com with SMTP id e125so7966997ybc.0 for ; Thu, 04 Aug 2016 12:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1JfDTJEs4ObrEQ8ptLfysUhqxBEQPkwMiueOJt4bq3E=; b=LvxEL2R1MI9qao8S8wnTfDo/V6bEeO4SMrvPE8skjYMdGQt8WIJAF/IwgEqMLZKIgp j6U2o4HcCHA756gOLwWYLw0k5Ozc9SBuXf81rF/IDyiDOxnYhY6oxxVABROGtQv5TAhL 6wU0ahLMtsBqb705Kf74LLrDqrRHiDeTYkb6k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1JfDTJEs4ObrEQ8ptLfysUhqxBEQPkwMiueOJt4bq3E=; b=h6sIDZKuLUonDb7X7rV9e9pCD0V7oijagdJWIWkqJIhawGc9jtOkplLibQH8a/ZDCa N2ba0wrOAiv2SferWjsvS6t5UuIkUQVhdoZGV5aKqlNpc1NBOOcAlA1DxDSZWSDtE5da Rx06lBq/FvBxwKrHx3cy6EBVv9T044ohK4FC8Oc8CkMnIEYGPqy+7q/vcXZtRQWFJWsN xh71AF5y2FkOnI0REOBHu751Y+1TtM826Ef8ywtsWexPzwmRHHOU1GLaE3h1RmIBbAkO LaXMnv7uLu632jPD7BVneRlIZW5HEf8XVpx/t5MBu6ooPa2jf/RZSLkEjlB0HgAi6ep1 Kinw== X-Gm-Message-State: AEkooutp7+/qZqWPJjJK3rWBQYdiejwLembYP/Jm+3V0O+eP2M/bierbIscuzKz782YXxMSQI3cI9CfQxf2TKjMi X-Received: by 10.37.50.12 with SMTP id y12mr39542yby.20.1470340071699; Thu, 04 Aug 2016 12:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.155.18 with HTTP; Thu, 4 Aug 2016 12:47:51 -0700 (PDT) In-Reply-To: References: <1470170269-20721-1-git-send-email-declan.doherty@intel.com> <5511822.hGlaykcsx3@xps13> <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> From: Jim Murphy Date: Thu, 4 Aug 2016 12:47:51 -0700 Message-ID: To: =?UTF-8?B?TWluZyBaaGFvKOi1teaYjik=?= Cc: "Doherty, Declan" , Thomas Monjalon , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 19:47:52 -0000 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 hugepages? Thanks, Jim On Wed, Aug 3, 2016 at 1:46 PM, Ming Zhao(=E8=B5=B5=E6=98=8E) 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 > 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 b= e > 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 fro= m > 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 ye= t > to find a C framework > > which come close to the usability and flexibility of the popular C++ > ones. > > > > > > >