From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC 0/4] Use Google Test as DPDK unit test framework Date: Tue, 02 Aug 2016 23:52:24 +0200 Message-ID: <5511822.hGlaykcsx3@xps13> References: <1470170269-20721-1-git-send-email-declan.doherty@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Declan Doherty Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 298A0214A for ; Tue, 2 Aug 2016 23:52:26 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id i5so309371482wmg.0 for ; Tue, 02 Aug 2016 14:52:26 -0700 (PDT) In-Reply-To: <1470170269-20721-1-git-send-email-declan.doherty@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-08-02 21:37, Declan Doherty: > I've been trying out using google test as a possible replacement for our unit > test framework and have put to together this series of patches with help from > Anatoly as RFC to get peoples thoughts on migrating to google test. Thanks for exploring new possibilities. > To facilitate google test this rfc patch set contains build system changes to > allow C++ to built within the DPDK framework, this intended for unit test code > only, and to support google test which is a C++ framework. Don't worry, I'm not > advocating making DPDK a C++ project :) 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. > 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)