Assess alpha beta release quality

[mwpowellhtx]

@ned14 This is more of a question than an issue, per se.

I'm curious about the repo. As stated in other forums, I'm looking for a more or less robust test API without necessarily requiring the heavy lift of something like Boost. That is where I need to clone a massive repository with direct, secondary, or tertiary dependencies.

Overall, this repo is alpha quality at best? Worst? Beta, nearing at least an early v0.9 release?

As mentioned earlier, this is a header only test API? Reading the front page I saw a lot of bravo sierra and fluff, but not a lot of substance that I could discern. Is this repo intended to replace Boost at all levels? Only for Boost.Test? As header only?

I took a look at the docs as well. It cross references the things in this repo fairly well, but I could not tell if there were any tutorials or anything, per se. Apart from the Boost docs themselves for guidance, I suppose.

On to my specific requirements. I've been using Catch for most test requirements, but I find I need a little better discernment around my Exception handling. Whether thrown is interesting in some cases, but I have a case where I want to predicate those Exceptions, like we're looking for a specific condition.

Additionally, we are doing scalability testing and therefore need the API to be thread safe. This was also mentioned, but I wanted to double check that.

Cheers!

[ned14]

Overall, this repo is alpha quality at best? Worst? Beta, nearing at least an early v0.9 release?

Definitely alpha. All my other libraries use it as a dependency, so it gets lots of testing.

As mentioned earlier, this is a header only test API?

Yes.

Reading the front page I saw a lot of bravo sierra and fluff, but not a lot of substance that I could discern.

It implements everything documented on the front page. Not sure why you'd consider that "bravo sierra and fluff".

Is this repo intended to replace Boost at all levels? Only for Boost.Test? As header only?

It's widely known amongst the C++ leadership that QuickCppLib is my vision for a Boost 2.0, or rather, the framework for a new collection of standards aspiring libraries incubating future C++ standard libraries. But it's not ready for others to use it, it's not fully baked. So I don't advertise it, I don't document it.

I took a look at the docs as well. It cross references the things in this repo fairly well, but I could not tell if there were any tutorials or anything, per se. Apart from the Boost docs themselves for guidance, I suppose.

It's undocumented apart from the reference API docs from doxygen. None of the cmake is documented.

On to my specific requirements. I've been using Catch for most test requirements, but I find I need a little better discernment around my Exception handling. Whether thrown is interesting in some cases, but I have a case where I want to predicate those Exceptions, like we're looking for a specific condition.

Like, CATCH_CHECK_THROWS_AS()?

Additionally, we are doing scalability testing and therefore need the API to be thread safe. This was also mentioned, but I wanted to double check that.

If it succeeds, it increments an atomic variable. If it fails, it prints the failing expression and increments an atomic variable. It's very simple.

[mwpowellhtx]

@ned14 I'm looking for a thread-safe test library that I can begin using today.

Catch was present my direction, and is fairly full featured, but for these couple of critical areas. No clear idea on when a v2 would be released, either. I'm okay with an alpha, per se; you say you are using the test framework, for example. So it must be good enough, of you wouldn't be using it?

How far from "fully baked" would you say it is? I noticed a version in the CMake, for instance, 0.1.

I don't really care about a "build" step, per se, after CMake git clones for test usage. Unless I need to care about that?

So if I am just using the unit test header only portion, I can skip the build, per se.

ExternalProject_Add (download_quickcpplib
    GIT_REPOSITORY git@github.com:ned14/quickcpplib.git
    GIT_TAG ${QUICKCXXLIB_GIT_TAG}
    GIT_PROGRESS ON
    SOURCE_DIR ${QUICKCXXLIP_GIT_REPO_DIR}
    CMAKE_ARGS -DPROJECT_IS_DEPENDENCY:bool=ON -Dquickcpplib_DISABLE_DOC_GEN:bool=ON
    LOG_DOWNLOAD ON
    CONFIGURE_COMMAND cmake -E echo "Skipping configure step."
    BUILD_COMMAND cmake -E echo "Skipping build step."
    INSTALL_COMMAND cmake -E echo "Skipping install step."
    TEST_COMMAND cmake -E echo "Skipping test step."
)

[ned14]

@ned14 I'm looking for a thread-safe test library that I can begin using today.

This one in quickcpplib is extremely simple. It's actually very powerful for it, I've been using it in anger for over a year and as I was telling Phil last time we met, he might start thinking of "less is more" for CATCH.

But mine is also specifically designed for Travis and Appveyor and CDash in particular. It's "hard coded" for that very specific combination. So, for example, it doesn't redirect iostreams because printing to the console gets captured by CDash and Travis and Appveyor. So leave out iostreams redirection entirely as superfluous to needs.

We also don't capture why something failed, we just keep a count of successes and failures, just enough to generate a JUnit XML file which can be fed to CDash, Jenkins or Appveyor. Due to not keeping state, we don't need to use mutexes. Simpler makes for better.

Catch was present my direction, and is fairly full featured, but for these couple of critical areas. No clear idea on when a v2 would be released, either. I'm okay with an alpha, per se; you say you are using the test framework, for example. So it must be good enough, of you wouldn't be using it?

Phil's conservative when he says v2 CATCH isn't ready. He's been using it personally for nearly a year now at work.

How far from "fully baked" would you say it is? I noticed a version in the CMake, for instance, 0.1.

The unit test implementation is so simple that you can audit it for bakedness by hand. Just walk the code. It's ridiculously simple. The fact it can replace 95% of Boost.Test use cases as is is amazing, but not surprising. Gennady would correctly point out that very few properly use Boost.Test's full capabilities.

So if I am just using the unit test header only portion, I can skip the build, per se.

Oh yes, no need to build anything in QuickCppLib. It's all header only. Add in the git submodule, include "boost/test/unit_test.hpp", it should all work if you're on a C++ 14 conforming compiler.