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]>
> > 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
> > 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 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
> 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...
> : https://github.com/pfultz2/Prove
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk