Re: Interest in a C++20 Unit Testing Framework?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a C++20 Unit Testing Framework?

Boost - Dev mailing list

> On 21. Nov 2019, at 16:23, Krzysztof Jusiak via Boost <[hidden email]> wrote:
>
> 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?
>
> Github: https://github.com/boost-experimental/ut

It is impressive. I didn't know that catch2 takes so much computation time. Could you include Boost.Test and lightweight_test from Boost.Core in your benchmark?

The small binary size and compilation time suggests that some of the tests are completely evaluated at compile-time. Is that what happens?

Syntax-wise, the absence of macros is impressive, although there is a steep price to pay, I have to writing out lambdas and literals excessively, which leads to a lot of squiggly characters to type. I don't like macros, but the downsides of macros are not relevant in a test framework.

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a C++20 Unit Testing Framework?

Boost - Dev mailing list
On 22.11.19 14:36, Hans Dembinski via Boost wrote:

>
>> On 21. Nov 2019, at 16:23, Krzysztof Jusiak via Boost <[hidden email]> wrote:
>>
>> 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?
>>
>> Github: https://github.com/boost-experimental/ut
>
> It is impressive. I didn't know that catch2 takes so much computation time. Could you include Boost.Test and lightweight_test from Boost.Core in your benchmark?
I would also be interested by that!

> The small binary size and compilation time suggests that some of the tests are completely evaluated at compile-time. Is that what happens?
>
> Syntax-wise, the absence of macros is impressive, although there is a steep price to pay, I have to writing out lambdas and literals excessively, which leads to a lot of squiggly characters to type. I don't like macros, but the downsides of macros are not relevant in a test framework.

I also agree with this: lack of macros is not IMO a selling point,
except when it comes to the dependencies that are pulled to get
something powerful enough in the preprocessor (like this is the case
with boost.test and its dependency to boost.preprocess).

Raffi


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a C++20 Unit Testing Framework?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> On 21 Nov 2019, at 16:23, Krzysztof Jusiak via Boost <[hidden email]> wrote:
>
> Hi,
>
> 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?

From a quick look I think this is an interesting project with some impressive results.   I can probably not use it any time soon in its current form and shape for other than some test projects.  That may change sooner than I think, as newer compilers supporting C++20 may become generally used where I work and all testing of our projects can assume C++20 is available.  For many existing projects this may take some time, or never be feasible,  based on their code base, target platforms, as well as time and funding to do migrations.  Even new projects may be required to support older C++ dialects.  Hence, one downside of this sort of project is that the potential number of users are not large from the get-go.  For many potential users there are alternatives that are more accessible and hence more feasible choices.  As we can see in this thread, some seems to declare their dis-interest in the library on this basis.  I think that is unfortunate and wanted to voice my view of support and interest.

If there is a home for a project like this, why is that not in boost?  Even though there may be several iterations with refinements before such a project reach its stable interfaces and concepts.  To get there, and then possibly on that basis provide interfaces for or influence standardizing of unit testing, we need someone to explore this space.  There is not going to be a MACRO based standard unit test library.  Are there anyone here that is disputing that?  If we agree on that, then in my view it follows that Boost is the right home for this sort of project.

Reading the examples, there are parts of how test cases are defined that I at best need time to get used too.  But worst is that I assume this is so as there are not limitless options given that one are not using macros, even in C++20.  So there may be valid arguments that the language is not ready for this yet even with source_location in the standard.  Compile time reflection did not make it into C++20, and I can envision it might have provided better alternatives, but I am not sure nor an expert.  I am also sure there are other wrinkles in this library that need to be ironed out.  This may happen before an eventual acceptance into boost, or later if included while a Boost library evolving toward a good model for standardized unit test facilities for C++.  I suspect some  

I hope there are sufficient support for this project and similar projects in Boost.  I think such projects will have better chances of success than outside of Boost.  In addition, Boost libraries are accessible to developers in many companies where other libraries are generally not.  If not accepted into Boost, then I am sure we soon will see this or similar libraries evolve or be invented outside of Boost.  Given that scenario, I would be left to wonder what the Boost mission is about.  At least part of it I hope is still to push the boundaries of what can be done in C++ and what C++ will become.


Bjørn


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost