Official project hiatus until 26 November, 2020

[pjohnmeyer]

I have updated the README to announce this hiatus. Those who follow this project know that maintenance has been rare and sporadic for a while now. As of today I am officially announcing a hiatus, as opposed to just letting things continue to linger.

On or about 1 October I will announce my plans for the project going forward. I do not know what those are yet.

Subscribe to this issue for updates.

[pjohnmeyer]

Extended to 15 October.

[pjohnmeyer]

I am currently of two minds.

1. Archive the project.

There are lots of fine alternatives out there, and UnitTest++ does what it does. It works for the people it works for, but it really doesn't need to be worked on anymore. There are many good alternatives out there such as Catch 2, doctest, Google Test, etc. for folks that want something newer and shinier. If you need to add something to UnitTest++ for your project, you can write your own checks and reporters reasonably easily. If something doesn't quite work for your compiler, you can fork it, and that fork is cheap because the library will no longer be a moving target.

2. Reorganize the project into a two-file library (one header file, one implementation file) before starting work on it again.

The most frustrating thing about working on this project, for me, is the amount of work that goes into CMake files and autoconf files and packaging releases, etc. These just aren't things I care to spend my time on, especially since I don't use C++ on a day-to-day basis anymore. A simple two-file library eliminates this pain point, allowing myself and contributors to just focus on the core -- and it's easy to just drop two files into whatever project you are using.

If that were done, it might be interesting to try again to add in some new features, or set up CI for "weird" compilers using GitHub Actions + External Runners... or whatever. But the current state of things is an obstacle to my desire to work on UnitTest++.

---

A third option would be to find a new maintainer, but I've not really seen any interest when I have asked in the past, and I don't see the need.

Hiatus extended to 26 November. Comments welcome.

[pjohnmeyer]

Forgot to unlock conversation after the previous update; unlocked now.

[cecilios]

Thank you for your time maintaining this project and for your thoughts. I perfectly understand your frustrations with cmake, compilers, other build tools and platform differences, as that's my frustration too with my projects!

I use UnitTest++ in my projects. It has been working perfectly for me many many years and I never found any issue. The only need I once had was documentation to write a custom reporter, but I could manage. IMO the library does not need more features and, so the library maintenance could be reduced to occasional fixes to deal with new compiler checks causing compilation warnings.

Between options 1 and 2, I would prefer option 2: a solution based on a few .cpp and .h files that I could add to my projects source code. It will also have the important advantage of removing an external dependency. For you, this option will also remove all your frustrations with building tools and will allow you to continue and enjoy with this excellent project.

Thank you!

[spaulaus]

I too would like to express my gratitude for your work on this project. Being such a light weight library has been incredibly helpful to me. I too think Option 2 is a low maintenance idea. It's low overhead to include a few additional files in a project.

[ohz10]

@pjohnmeyer, thanks for guiding the project these last couple of years. After all these years, this is still my favorite minimalist test framework for C++. I would prefer to see option 2 adopted.

[thedrbubba]

@pjohnmeyer I, too, want to think you for all you have done for UT++. I started using it back in 2007. We still use it on that project I started using it on. We have had very few issues with UT++ over all these years.

FWIW,
I would prefer the see option 2 adopted.

[pjohnmeyer]

Thanks @cecilios , @spaulaus , @SenorAgosto , and @thedrbubba for the kind words and feedback. I spent a few hours tinkering with option 2 last night and I felt somewhat reinvigorated by it. I'm not saying it's going to happen, but I'm not saying it's not going to happen.

[filiatra]

@pjohnmeyer Thank you for UT++, have been using it for many years; it is an excellent tool for making software.
I am skeptic about making a single implementation file. Reorganizing and cleaning up the repository yes, but a single header for all the classes will make it harder to maintain but also to contribute to...
Removing autotools completely and keeping few clean simple cmakefiles would be my suggestion.

[grahamreeds]

The usual way of making a single header file is via a post process that concatenates the files together. GR

…

Sent from my Nexus 10

On Fri, 19 Feb 2021, 12:21 Angelos Mantzaflaris (Άγγελος Μαντζαφλάρης), < ***@***.***> wrote: @pjohnmeyer <https://github.com/pjohnmeyer> Thank you for UT++, have been using it for many years; it is an excellent tool for making software. I am skeptic about making a single implementation file. Reorganizing and cleaning up the repository yes, but a single header for all the classes will make it harder to maintain but also to contribute to... Removing autotools completely and keeping few clean simple cmakefiles would be my suggestion. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGL3HH655AXRBCGR3TIYJDS7ZJTNANCNFSM4QCPMBLQ> .

[xparq]

Late to a party that's long over, too, but just to make it explicit: you don't need to ever archive the project. It's fine as-is, just keep it available, please. I'm actually new to it (seen it embedded in some other prj). Looks like a nice, clean, self-containing, balanced package (with somehow a better vibe than e.g. Catch2, which I've always postponed to integrate).

As to CMake: for one, I'm reluctant to use it anyway. E.g. just cloned your stuff, did a cl -c -EHsc -std:c++17 *.cpp (plus the Win32 timing module) from muscle memory, then shoved all into a .lib and I had my first test running the next minute.

(It's quite a sight (however unsurprising) to see CMake having the superpower to kill (the spirit) of otherwise simple, straightforward, friendly projects by causing a lot more trouble than it solves.)

[gregkrsak]

👍 Good write-up. I'm really happy I'm not the only person who thinks that about CMake.

…

On Sun, Feb 20, 2022, 4:13 PM Szabi ***@***.***> wrote: Late to a party that's long over, too, but just to make it explicit: you don't need to ever archive the project. It's fine as-is, just keep it available, please. I'm actually new to it (seen it embedded in some other prj). Looks like a nice, clean, self-containing package (with somehow a better vibe than e.g. Catch2, which I've been somehow reluctant to integrate). As to CMake etc.: for one, I'm reluctant to use it anyway. E.g. just cloned your stuff, did a cl -c -EHsc -std:c++17 *.cpp (plus the Win32 timing module), shoved all into a .lib and I've had my first test-test running the next minutes. (It's quite a sight (however unusual) to see CMake having the superpower to kill (the spirit) of otherwise simple, straightforward, friendly projects by causing a lot more trouble than it solves.) — Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKRQ36QL5JP5AHKSTPO57DU4F7SVANCNFSM4QCPMBLQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[BeenEncoded]

This was my unit test library of choice for a long time due to its simplicity. Many thanks for your contributions @pjohnmeyer .

[modem-man-gmx]

Archiving this would perhaps have a bad influence on the recent integration in CodeLight IDE. So I be you to not completely kick it off. Could it get any other solution? It works like a charm and I do not see any CVS reports comming up, so ... just let it as it is?

[jwellbelove]

I've been using UnitTest++ for over seven years, but I use a forked version that I've added a couple of extra checks to.
The most recent one was to accommodate C++20's changes to to the stream API. Previously a char stream would accept a wchar_t. char16_t and char32_t, where it would print the value (rather than the character). In C++20 those functions have been marked as = delete making the standard UnitTest++ checks fail compilation for lines such as CHECK_EQUAL(L'A', L'B');. I'm happy to continue using my fork for the present as I can't see that there are any major issues that need addressing (apart from the above).

[modem-man-gmx]

... I use a forked version that I've added a couple of extra checks to. The most recent one was to accommodate C++20's changes to to the stream API. ... I'm happy to continue using my fork for the present as I can't see that there are any major issues that need addressing (apart from the above).

Good to know! I am still at C++17, sound like I'm facing this issue in near future.
Would you please tell us the branch, so everyone could participate?

Or even better - could we all together continue the project? Under the lead of some experienced developer, like ... You?

[jwellbelove]

Or even better - could we all together continue the project? Under the lead of some experienced developer, like ... You?

A tempting idea; I wish I had the spare time. I have my own GitHub project that takes up a lot of it already.
Embedded Template Library

I was actually looking into moving to Google test as it's still in continuous development and has a few interesting features like 'matchers' among others and the ability to stream your own text on to the end of a failed test.

[jwellbelove]

Would you please tell us the branch, so everyone could participate?

My fork is currently integrated as a sub-folder in the ETL project.
https://github.com/ETLCPP/etl/tree/master/test/UnitTest%2B%2B

[spaulaus]

As much as I loved this framework, I had to move because of the c++ standards shifts. For those looking for an alternative framework, I've used Doctest for a couple years now. It's a header only implementation. I found migration to be fairly straightforward.

Obligatory disclaimer: I'm not in any way affiliated with the Doctest project.

[neacsum]

I apologize for the shameless self-promotion but, if you are looking for testing framework compatible with UnitTest++, you might visit my UTPP project. It was started as a re-implementation of UnitTest++ but it is now a header-only library (nothing to build). It supports C++20 and is somewhat more compatible with GoogleTest.

[modem-man-gmx]

if you are looking for testing framework compatible with UnitTest++, you might visit my UTPP project. It was started as a re-implementation of UnitTest++ but it is now a header-only library (nothing to build). It supports C++20 and is somewhat more compatible with GoogleTest.

Sounds interesting to me!
Perhaps a way to convince Eran Ifrah to no discontinue UnitTest++ integration in CodeLite IDE, but to switch over to UTPP instead?

In the meantime I worked with Lightest. It has no special integration in CodeLite, just the normal way of all make tools. So I'm still searching a 1-by-1 replacement for UnitTest++.
Anyway, Lightest is also usable as a header-only lib and this way easily to be integrated in github actions. Since then, I'd always prefer header-only test libs.