January, 2018

Wednesday, January 24th, 2018

Microtests and Test Frameworks

I’m a big fan of microtests – both the term and the thing itself. My friend Hill coined the term quite a while back and I felt it completely solved the problem of ambiguity we agile folks were having when we talked about unit tests in front of people who understood the term in the way it was used 30 or more years ago.

I’m not going to describe what microtests are here. If you aren’t familiar with the term, go watch Hill’s video clip about them right now. We’ll talk more later.

Back already? Great! So… a while back I started to wonder if the NUnit test framework, which I have worked on since 2004, might be leading people to write bigger and more complex tests by having too many features. What would happen, I asked myself, if a framework only had those features that support microtests. And by the way… what features would that be?

I asked the question to a group of experienced coaches and – as you might expect – I got varying answers. Some people thought it was a good idea while others felt that having a separate tool for microtests would be a burden. There was a fair amount of agreement about what features were needed but also some disagreement on specific items.

I’ve decided to start out with a specification of features that will be most useful in microtests. There could be separate frameworks to support those features or you could just use a standard test framework and limit yourself to a particular subset. A framework could even support a setting that would warn you if you got out of the usual territory for microtests.

So here’s my short list of features at least for now. Let me know what you think of it.

1. A full set of assertions, such as are supported by nunit or junit. Assertions designed for access to the file system or databases, however, would be excluded.

2. A full set of test-identification attributes, including those that support data-driven tests.

3. Some way to create shared setup and teardown for tests. This is controversial as some people think it’s an antipattern to use separate setup methods. In the end, I decided it should be available but de-emphasized. Higher-level setup (fixture, namespace, assembly) would not be supported, however.

4. Simple reporting of test results without adding on any extra components.

5. NOTHING else, at least initially. In particular, NO way to order tests or define dependencies between them.

Tell me what you think of the list. Would you use such a framework if it existed?

Tuesday, January 23rd, 2018

Future of NUnit

A while back I began to have some concern about the future of NUnit. I was entering my 70s and I knew I wanted to spend more time on other things. NUnit had been very much my project for a few years and I didn’t want it to die when I was no longer maintaining it.

Starting about three years ago, we began the process of phasing me out of the project. It was difficult and time-consuming but now the transition is pretty well complete. Today, we have a much larger group of contributors and team members than ever before. I’m still involved but my level of participation is much reduced.

The NUnit Project is now run by a team (the Core Team) rather than an individual and is supported by the .NET foundation. The Core Team consists of Rob Prouse (chair), Terje Sandstrom, Chris Maddock, Joseph Musser and myself. The Core Team makes the big decisions, similar to a board of directors, rather than running individual projects. Each of the projects under NUnit has it’s own team and team leader, although there is a fair amount of overlap. I think that’s a great formula for future success.

With a decentralized structure like this, there is both an opportunity and a need for more people to step up into leadership positions. I hope more people will join the developers of NUnit as time goes on and that some of you who have been involved for a while will consider taking responsibility for some of the projects or subprojects we operate.

For myself, I’ll continue to be a member of the Core Team and will continue to contribute to the codebase. But most of my open source work will be in other projects, some related to NUnit and some more independent. I’ll be posting here about some of the things I’m working on as they come closer to fruition, so please follow me here if you are interested.