(1) I used gtest for an other project before, and it was pretty nice. Although I'm not so familiar with test frameworks, I think it's a good choice. At least, perspective of features. If I have to bring up one sad thing, it isn't provided with any packaging system (e.g. rpm, brew), afaik. So, initial setup might be tricky.
(2) I think we can't make better choice without examples. So bringing own favorite test frameworks and keeping it offline may cause chaos but I think it's a right way. My only concern is that the unit tests might not be keep updated. Committers should keep eye on the tests, and run it before approving PRs. It would be great if we could run all the unit tests on our (some of) CI platforms without any pains (like disable tests if the test framework is not available on the platform), then we can assure the test cases themselves are still valid. Thanks, Masakazu On Sat, May 20, 2017 at 8:12 PM, <gan...@apache.org> wrote: > Hi trafficserver-dev, > > > (1) I was wondering if we have any preference for a C/C++ unit test > framework in the ATS community. > > Background and thoughts: > > I needed a unit test framework quickly to do TDD in order to deliver the > AWS auth v4 (PR #1946). > Google Test seemed easy to bootstrap, popular, feature rich and easy to > use, also its license is "BSD 3-clauses”. > The unit tests I wrote (PR# 1953) got the work done, they don't do > anything fancy or Google Test specific and can be converted to use any > other framework of our choice. > > > (2) I was wondering what to do with the unit tests until we decide on a > unit test framework that we all going to use. > > Background and thoughts: > > People have concerns that if every developer starts checking into master > unit tests using frameworks of their choice (even if not run) we will end > up with a mess/chaos. > > I understand the benefits of having one or two agreed upon frameworks and > run all our tests with every build. > > I have a similar case with the cachekey plugin tests where I used the > “old” TSQA framework (at the time) which I still run to test for > regressions and enhance when I make changes. > If we plan to rip out the “old” TSQA framework should I then remove those > tests from the source tree until I convert them to “autest"? > > My personal take is that in both examples (s3_auth_v3 and cachekey) the > tests have 100% code and very high branch coverage (the wonders of TDD) so > it would be a pity to rip them out and keep them some else until converted. > If they are checked into the source tree we could still use them “offline” > to test for regressions in meanwhile, also they will be available to anyone > to work on them and would be a pretty good starting point for bringing the > tests up-to-date to the agreed upon framework when we have a chance. > > > Any ideas and thoughts on (1) and (2) are greatly appreciated! > > Cheers, > —Gancho
