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-23 09:07:32

> On May 23, 2016, at 4:14 AM, Viktor Kirilov <vik.kirilov_at_[hidden]> wrote:
> 
> 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

It is not that much more feature-rich than the Prove library. The Prove library is missing things like asserting for an exception and floating-point comparison(which I hope to add), but it already supports things like parametrized tests. Adding the missing features won’t make the Prove library reach 3K LOC. So I disagree with the ‘lightest’.