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.