From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id F068B37A4 for ; Wed, 3 Aug 2016 22:46:37 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id o80so353288007wme.1 for ; Wed, 03 Aug 2016 13:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=luminatewireless-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MgsXP2KqaIcR/mmaZ9EDMe/1jROVndZCqGwccmh3590=; b=C6jMtBdUrKC2CePEw9mS1J4+axowANbDHholSwIWeTM9RuuoOl+WOBQgD1T59sQHmI EXiAYskWn7X9sVIX6qVbJ9/AgtTErnplMClwQ+WHTE3DF0i2S6UdR0OCQkbxMkV8PZpN rLpRh8MM56KucTg+/x75EVTksyNofJjuecUONunWjzUiOZGbObfxCMCOZOc6Z3Mn7h2J MnBGJd3WxHfpuh4GYGfqWQ5mfxXrVb+2Ye3T1vrxF+PiVWdEoLWCUyKlgxMsndeT0zLe HvELGu3oG0ogsYRM0oe4Y4yEkEh86d851gwdJN5g4h3WPR5xhIHv1DvjV/SRpFjNBINm +ePg== 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=MgsXP2KqaIcR/mmaZ9EDMe/1jROVndZCqGwccmh3590=; b=fLs3x2sGzJrZDvqBfBOfR9jpkxrAd0x5plMXRwMVz9QMG9kmMaS7EGP6jzuMaWh+ja J5yt4B49vO1aVInZZMHH9PNgoO+K4KY0A/2kBNbc4aRGX5AWWXL6MbxfDTtQwZ/xhWLx zIhf5ylIY2HEeb3yLEwCxRM4FME18XlOrEeTAr27DVJ5bSqPgBm71hELwiHGTQrusug3 LbVLS4ViwuXbgH1ahNOPIWlDb0XqnUXNEYsvWvwj9pepL25IG/Ew5TqC+vKCkdBUyTqK PzKZojsWe7+P4PJQwl2enOtuGvZJLmUZ9f/IAiDagQc9N6fDRlO17MbkW4+NHFm+ZAZm lysQ== X-Gm-Message-State: AEkoouv3v6+Xs4Z5wFCbCAHc0Uu6ZF5B9/UuHcBOnca1GrMre3Hflk4Fqc+hgD60O//HIb7uOVXEg8mp8Nac4d/r X-Received: by 10.28.216.75 with SMTP id p72mr27531231wmg.67.1470257197559; Wed, 03 Aug 2016 13:46:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.74.136 with HTTP; Wed, 3 Aug 2016 13:46:36 -0700 (PDT) In-Reply-To: <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> References: <1470170269-20721-1-git-send-email-declan.doherty@intel.com> <5511822.hGlaykcsx3@xps13> <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> From: =?UTF-8?B?TWluZyBaaGFvKOi1teaYjik=?= Date: Wed, 3 Aug 2016 13:46:36 -0700 Message-ID: To: "Doherty, Declan" Cc: Thomas Monjalon , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 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: Wed, 03 Aug 2016 20:46:38 -0000 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 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. > > >