As I had noted previously that I didn't believe UnitTest++ needed a 2.x series and that a 2.x line would only be for breaking previous tests - essentially what you class as v3.

The reasons I use UnitTest++:

• I have a corpus of several thousand test at this and previous companies I have worked at.
• I am comfortable with UT++
• I use compilers that are generally old (currently embedded system that has 4.8.4 so majority of c++11 but generally corner cases involve workarounds) and I know UT++ will Just Work.

Most new programmers seem to have experience of GoogleTest - primarily because of the name. As a dev who remembers using CppUnit and when Noel and Charles did their review of the landscape and pretty much reached the same conclusion as everyone else (but actually did something about it) I am glad that there are a lot of testing frameworks that are as it means that programmers will be more likely to unit test and that is a Good Thing.

If I were to join a firm that already used GTest, Boost.Test or Catch or TheLatestFramework then I would begrudgingly use that.

One final non-conclusive point is that those aforementioned kids seem to equate relevance with newness and the last time there was an interface breaking update.

One thing I always get narked at is macros and the fact they pollute everywhere. I have had an idea of test(f()) being a function call you pass a lambda to but never took it anywhere - too busy writing tests for my day job!

Thanks for the feedback. I think a lot of the people who use UnitTest++ use it for similar reasons; it's stable and "just works." I'll be interested to hear from others as well; I may even throw together a survey and see if I can get anything concrete.

As I had noted previously that I didn't believe UnitTest++ needed a 2.x series and that a 2.x line would only be for breaking previous tests - essentially what you class as v3.

I don't want to revisit the conversation about 2.x; the how and why of that breaking change was thoroughly covered. I will, however, say that if I were to create a 3.x line the macro interface would go largely, possibly entirely unchanged -- the primary breakages would likely be in compiler / toolchain compatibility, and possibly in some of the underlying classes that some users may have extended.

One thing I always get narked at is macros and the fact they pollute everywhere.

There's almost no getting around it if you want filenames and line numbers in C++. There are some portable stack-trace libraries out there that might work, but I don't know if they are as portable as we'd like. Sinking the time into figuring that out just to avoid macro usage does not feel like time well-spent to me.

One nice thing about the macros tough, is that they tend to stand out from the rest of the code, leading to better readable tests imho.

To be honest, having worked with MsTest (C#) and Mocha/Chai (Node) I have to say that I don't mind mixed case testing functions. It would be hard to get something like Chai in C++ though:
function(value, err) { value.should.be.greater.than.zero(); }

What I would like to know is what real improvements you would like to bring going forward? What features would you need to accomplish this?

The only reason why I went with UnitTest++ is the simplicity, It does everything I need it to and nothing else. I think it could actually even be simpiler. I'd love it if it was a single header library for example like these: https://github.com/nothings/single_file_libs

@rlabrecque perhaps you're in for lest (a 'CATCH lite') then?

My feeling is that you get simplicity from including a single header file, but every time you compile you have build that file whereas with a lib, the building has been done already.

That's correct in case of lest, not so much in case of CATCH.

In case of CATCH-like frameworks, the simplicity also comes in the form of fewer assertion macros and of locating fixtures at the spot of the test code itself. Further, CATCH goes out of it's way to separate building framework code from code needed in the tests, whereas lest does not do that.

What I would like to know is what real improvements you would like to bring going forward? What features would you need to accomplish this?

@rlabrecque Good question. I'm not sure how deep I want to go into it b/c I don't like publishing ideas before I actually have time to work on them, but a sampling of the things bubbling around have been:

• Add a single-file option, or make it the only option (I am a big fan of Catch in a lot of ways, and this is one of them)
• Make it easier to write and use custom TestReporter classes
• Add custom failure messages to CHECK* macros (without adding additional macros like some libs do)
• Improve C++11 and beyond support

All of these things can be accomplished without going to a 3.x, but become easier if I drop the requirement for public API compatibility. Also, some of them make the others easier; for example, the single file option and the C++11 bullets could each make the other easier to implement if one is done first.

My feeling is that you get simplicity from including a single header file, but every time you compile you have build that file whereas with a lib, the building has been done already.

@grahamreeds as @martinmoene points out Catch has successfully addressed that, at least to a certain degree. I have not spent enough time with it recently to know how it holds up in terms of compiler compatibility, but it claims to only require C++98 and the standard library. On the other hand I don't necessarily agree that Catch offers much else in the realm of simplicity despite the claims, but a full critique of Catch is one that I am not prepared to make in this thread for two reasons:

• I have not spent enough time with Catch yet to offer a well-reasoned critique
• It is out of scope for this conversation