For full up plugin testing we (Yahoo!) are using the AUTest framework. In fact there are already plugin based tests checked in to master (see tests/gold_tests/pluginTests/header_rewrite for an example). I think that is fine for testing the plugin in situ and we should adopt it as our preferred platform. If you have TSQA tests, those should be ported to AUTest. If you want to test a C plugin it works just as well as testing a C++ one. If we are going to test plugins as plugins, I think AUTest is the correct approach. I would like, over the long run, to change all of the current regression tests to either real unit tests or full up AUTest based.
Unit testing is a bit different, and more akin to "make check" where autonomous programs run to test low level features of the plugin code. This is currently done mostly via either hand rolled code (e.g. test_Map.cc) or using TestBox in a regression test. This is more of testing modules or classes in a plugin rather than an explicit plugin test and would (I presume) be used in the core as well. I looked at the Google Mocks stuff and PR 408 and I was not very impressed. It did not seem like a good test setup. Google Test, at least, seems somewhat useful (quite reminiscent of lib/ts/TestBox.h). In any case, as I commented on Gancho's PR for that, it needs to be integrated so, at a minimum, the make files detect the use or non-use of the test framework and do the right thing, rather than failing annoyingly. In essence, it needs to be handled in the same way as other auto tools modules, such as libxml or do as James suggested and directly bundle it as with Lua.
