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: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-05-22 21:09:41

> On May 22, 2016, at 7:12 AM, Viktor Kirilov <vik.kirilov_at_[hidden]> wrote:
> 
> Hello!
> 
> I just released doctest - https://github.com/onqtam/doctest
> All the info about it can be found on github.
> 
> So do you think it can enter the boost project? How much work will it take
> to get it into boost except for adding boost in the title?
> Will it or boost benefit from that addition?
> 
> Also I've sort-of followed the Best Practice Handbook (I consider it very
> valuable) as much as possible -
> https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook
> 
> Any feedback will be greatly appreciated. Thanks!

> everything testing-related can be removed from the binary executable by defining the DOCTEST_CONFIG_DISABLE identifier

I’ve embedded my tests in the source code before, and I will say that its a bad idea for lots of reasons: no isolation, not testing actual final product, and slower tests.

> very small and easy to integrate - single header - less than 3k LOC in the implementation translation unit and less than 1.5k LOC everywhere else - extremely low footprint on compile times

Hmm, I don’t think its fair to say it is the lightest or small as the single header is almost 3K lines of code. The Prove library[1] provides testing infrastructure(and parses the test expression similar to Catch) and it is only little over 400 lines of code, and it compiles pretty fast(although I haven’t ran benchmarks against doctest).

> If you don't want to provide an operator<< overload, or you want to convert your type differently for testing purposes, you can provide an overload for doctest::toString() for your type… Note that the function must be in the doctest namespace which itself must be in the global namespace.

Shouldn’t the function `toString` be found by ADL lookup? This way users don’t have to break into the `doctest` namespace.

> There are some cases where overloading toString does not work as expected.

What cases are those?

> Note that the type String is used when specializing StringMaker<T> or overloading toString() - it is the string type doctest works with. std::string is not an option for the library because then it would have to drag the <string> header with it.

I don’t see how that is a problem in real-world usage, since the standard headers such as string is probably already included, and now you seemed to be duplicating functionality, which only bloats compilation.

[1]: https://github.com/pfultz2/Prove