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 <declan.doherty at intel.com> 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. > > >