Boost logo

Boost :

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-11-22 21:28:12


(CC'ed to boost-users)

On Fri, 22 Nov 2019 at 21:53, Vinnie Falco via Boost
<boost_at_[hidden]> wrote:
> On Thu, Nov 21, 2019 at 7:24 AM Krzysztof Jusiak via Boost-users <boost-users_at_[hidden]>>
> > I was wondering whether there is any interest in exploring
> > a C++20 single header/single module, macro-free Unit
> > Testing Framework with no dependencies?
>
> I have no interest in a library that requires C++20, especially
> considering that C++20 is not even official yet but also because once
> C++20 is released, there will be hardly any users for many years. This
> project seems very much like it was written "just because", to use the
> latest language features, rather than for pragmatic reasons. I don't
> see anything compelling to use it over Boost.LightweightTest for
> example.

I had a look at the current documentation and examples,
and I'm glad to see I'm not the only sceptical about it.
My opinion is very similar to what Hans, Raffi and Vinnie explained.

Macros in testing and benchmarking frameworks are kosher,
in fact, they can be very helpul to organize and structure large
amount of tests that in turn makes it easier to search and browse
through the code. I can't imagine how any of the modern IDE's will
support the string-driven syntax.

As a long time maintainer of SOCI library, I'm no stranger to
the syntax-first library development [1], still, I find the UT's
string-based test cases approach as an interesting curiosity
with very little practical value. (It falls into similar drawer
as the (over)use of emoji in commit messages on GitHub :)).

Boost is known as a C++ guinea pigs playground, so any library can
make it in. If it does, I just hope Boost will not allow to adopt the UT
as a test framework of choice of any/too many of its libraries.

[1] https://www.drdobbs.com/database/a-simple-oracle-call-interface/184405930?pgno=2

Best regards,

-- 
Mateusz Loskot, http://mateusz.loskot.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk