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

On May 22, 2016, at 7:12 AM, Viktor Kirilov 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