From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 308782BE6 for ; Wed, 3 Aug 2016 11:57:43 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP; 03 Aug 2016 02:57:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,465,1464678000"; d="scan'208";a="149873523" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga004.fm.intel.com with ESMTP; 03 Aug 2016 02:57:41 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.102]) by IRSMSX102.ger.corp.intel.com ([169.254.2.123]) with mapi id 14.03.0248.002; Wed, 3 Aug 2016 10:57:39 +0100 From: "Doherty, Declan" To: Thomas Monjalon CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thread-Index: AQHR7P5QT782v1QN2UOa7VBG6KvDMKA2JY0AgADVNWA= Date: Wed, 3 Aug 2016 09:57:39 +0000 Message-ID: <345C63BAECC1AD42A2EC8C63AFFC3ADC2829180F@irsmsx105.ger.corp.intel.com> References: <1470170269-20721-1-git-send-email-declan.doherty@intel.com> <5511822.hGlaykcsx3@xps13> In-Reply-To: <5511822.hGlaykcsx3@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzY0Y2IyMjMtYWM2Ni00NWE0LWE1ODMtNjY2YzlhZmRkNDk2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjgzT1VRYW1RYVMxbGUzSittRjZ5bWx6S0hqUWh3QnNTSitsaUhma0QwaU09In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 09:57:43 -0000 > -----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 i= f it were not for the advantages you get from C++ test framework. Having work= ed with multiple C and C++ frameworks, I've found that one of the biggest advantage= s of the C++ frameworks is the amount of boilerplate code they can save you from wri= ting. 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++ c= ould easily understand the intent of the test code.=20 > > 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 tes= t > > execution framework which allow individual test suites or tests to be s= pecified > > 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. >=20 > It would be interesting to better describe in details what is missing cur= rently > 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 th= e command line No standard set of test assertions used across the test suites. No standard setup and teardown functions across test suites, state from pre= vious 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 applica= tion, but I would=20 question if it is effort worthwhile when we take an off the shelf framework= , which does all=20 those things and a whole lot more, which has been test and used in a huge v= ariety of projects.=20 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.