From: BjÃ¸rn Roald (bjorn.roald_at_[hidden])
Date: 2019-11-23 12:33:25
> On 21 Nov 2019, at 16:23, Krzysztof Jusiak via Boost <boost_at_[hidden]> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk