For 1), We have a long standing PR to add a unit test framework for C++ plugins. We also wrote tests for the webp transform plugin using that framework. We can revisit this and see if this is a good starting point. https://github.com/apache/trafficserver/pull/408
We still need a good unit test framework for C plugin, though. For 2) I also have tests for the ESI plugin but it is really not quite doing the things i want as well. So I don't mind rewriting them using whatever framework we agree to. IMO, When we come up with a plugin unit test framework we all agree to, we should require the stable plugins (i.e. those not in "experimental" directory) to use it. For experimental plugins, i think we can live do what Gancho suggested till those are converted to the agreed framework. Thanks. Kit 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
