A few years ago, in my blog post “Life in the 80s,” I wrote about my goals for the next decade of my life, my 80s. In a section titled “Do Less Programming,” I talked about reducing my coding activity to leave time for other activities. I planned to leave the NUnit project, my largest time commitment, at the end of 2022.
In fact, I did leave NUnit at that point but after a year or two, for a variety of reasons, I went back to working on the project, focusing on the NUnit engine. At this point, I have been part of the NUnit organization since 2004, with the exception of two relatively brief absences, the 2022 break being the second. Now, in 2026, I’m feeling that it’s time for another change.
In recent years, some things have become harder for me. Switching between projects, languages, styles of coding, etc. is no longer as easy as it once was. Oddly, it seems that smaller, more subtle changes are the most difficult. I’ve come up with the notion of “things that are different but deceptively similar” for this phenomenon.
As an example, I’ve been working in parallel on versions 3 and 4 of the NUnit engine. While some parts of the code change completely between the two versions, in most of it – probably 80% – the differences are sparsely distributed, small, subtle and hidden. To minimize the mental effort of switching between them, I typically work on one of the two versions for several days at a time.
As a further complication, I also work on the TestCentric Gui Runner. Until recently, it had its own engine, forked from NUnit. It also has two active versions, V1 and V2. So, considering just the engines, there are actually four “different but similar” codebases. An added problem for TestCentric was that its codebase, while not much smaller than NUnit’s, had only two developers working on it.
By the end of 2025, I could see that some simplification was needed and created a plan to reduce the size and complexity of the work. At a high level, it can be summarized as follows:
1. Produce a final V3 release of the NUnit Console Runner and Engine, and stop working on it.
2. Treat the latest V1 release of the TestCentric Gui Runner as final and stop further work.
3. Eliminate the TestCentric engine entirely, and rely exclusively on the NUnit engine.
4. Produce a 4.0 final release of the NUnit console and engine.
5. Produce a 2.0 final release of the TestCentric Gui Runner.
As I write this, items 1 to 3 are complete...
1. Version 3.22.0 of the NUnit console runner and engine are released. I will now focus exclusively on V4 development. If a critical need for an additional 3.x release should arise, someone else will need to take on the problem.
2. Version 1.7.1 of the TestCentric Gui Runner is now considered the last V1 release. This code is extremely stable, so it’s unlikely that a further update will be needed.
3. The latest builds of the V2 TestCentric Gui Runner no longer include a separate engine, but instead reference the NUnit engine. This is a significant reduction in the codebase, which is now almost entirely UI code.
Going forward, I’ll focus on items 4 and 5. Once the NUnit 4.0 release is final, I plan to leave my role as “lead” for the engine project but continue to make smaller contributions. I’ll probably continue to work on the TestCentric Gui Runner after its release but at some point, I hope hand over the leadership role there as well.
Even so, while I’m still able, I’ll keep on coding.