On 11/19/2015 09:44 PM, Bernd Schmidt wrote:
> It's one option, but it doesn't seem like the best one either. I was
> thinking of something not dissimilar to your approach, but with fewer
> bells and whistles. My class registrator would look something like this:
>
> static list<void (*)()> test_callbacks;
>
> class registrator
> {
> public:
> registrator (void (*)() cb)
> {
> test_callbacks.push_front (cb);
> }
> }
>
> (or use a vec if you can do that at global constructor time)
>
> and then you just walk the list and run the callbacks when you want to
> run tests. The one you have implements both the registration and a
> special case linked list, which just doesn't look right to me, and I
> think I'd also have avoided the runner class.
Google test allows to run tests which match a given regular expression.
This is very convenient when you debug a failing test: you just need to
run the testsuite under debugger and specify the relevant (failing) test
as a filter. I think this feature is worth implementing eventually
(maybe regex is an overkill, and matching against a substring will be
enough). So, if testcases are implemented as objects, it will easy to
add filtering. If testcases are just callbacks, names and possibly some
other metainformation need to be stored separately.
FWIW, I worked with other unit test frameworks, such as CppUnit (but
Google Test is superior, IMHO) and they use the same approach: testcases
are objects which store metainformation (such as name) and have methods
for running tests.
--
Regards,
Mikhail Maltsev
