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: Viktor Kirilov (vik.kirilov_at_[hidden])
Date: 2016-05-23 05:14:14

On Mon, May 23, 2016 at 4:09 AM, Paul Fultz II <pfultz2_at_[hidden]> wrote:

>
> > 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).
>
>
well it is not the "lightest", but the "lightest feature-rich" - there are
some tradeoffs made - and by light/transparent I mean the compile times -
and no warnings/namespace pollution - and not so much the header size.

> > 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.
>
>
after trying it on my own - I ended up taking everything related to
stringification from Catch - including the documentation... :D

> > 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.
>
>
true... but my String class is still very small, but still true...

> [1]: https://github.com/pfultz2/Prove
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>