Re: [boost] doctest - the lightest feature rich C++ single header testing framework - if it can enter boost and if it/boost will benefit from that

Subject: Re: [boost] doctest - the lightest feature rich C++ single header testing framework - if it can enter boost and if it/boost will benefit from that
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-05-22 22:05:49

On 23/05/2016 00:12, Viktor Kirilov wrote:
> I just released doctest - https://github.com/onqtam/doctest
> All the info about it can be found on github.

I like REQUIRE/CHECK/WARN levels.

I *really* like SUBCASEs.

Although one thing that seems a bit lacking with that syntax is support 
for TearDown that executes even on test failure / exception.  I guess 
the equivalent is writing RAII guards, but these can be annoying.  An 
execute-lambda-on-destructor class included in the framework can reduce 
the pain of this (or including explicit teardown syntax).

> This allows the library to be used in more ways than any other -
> testscan be written directly in the production code!

I'm not convinced that this is useful beyond small utility functions (as 
demonstrated in the tutorial).  "Real" tests often have other 
requirements (mocking frameworks or hand-made mocks, library 
substitutions [eg. in-memory db], alternate logging/output, helper 
methods, etc) that you'd typically want to keep out of the production code.

OTOH, it does make checking whether methods are covered by tests a bit 
easier if the test is right next to the method -- but [a] this is what 
coverage tools are for and [b] it's likely the test case wouldn't be 
close to the method implementation if the class requires complex setup 
(since it would be a subcase instead).

Once tests get sufficiently large it's easier to have them in a separate 
file anyway so you can toggle between the test and the code under test 
quickly.  (Many editors are better at jumping between files rather than 
multiple points within a single file.)

I realise that these things are still possible with doctest, but if this 
wasn't a goal then I think it would simplify things or increase 
consistency, such as avoiding the issue with ensuring just one 
instantiation of the test runner / main.