From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9F30A2BF7 for ; Wed, 3 Aug 2016 14:51:18 +0200 (CEST) Received: from cpe-2606-a000-111b-40ed-7aac-c0ff-fec2-933b.dyn6.twc.com ([2606:a000:111b:40ed:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1bUvdh-0004N1-9D; Wed, 03 Aug 2016 08:51:15 -0400 Date: Wed, 3 Aug 2016 08:51:06 -0400 From: Neil Horman To: "Doherty, Declan" Cc: Thomas Monjalon , "dev@dpdk.org" Message-ID: <20160803125106.GC3603@hmsreliant.think-freely.org> References: <1470170269-20721-1-git-send-email-declan.doherty@intel.com> <5511822.hGlaykcsx3@xps13> <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.6.2 (2016-07-01) X-Spam-Score: -1.0 (-) X-Spam-Status: No 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 12:51:18 -0000 On Wed, Aug 03, 2016 at 09:57:39AM +0000, 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 think libcheck: https://libcheck.github.io/check/ Ticks most of those boxes, or can have the missing functionality added fairly easily. > 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. > > > >