Dotnetifying Testing.Commons


It should be no secret that I have been very absent from both my OSS libraries and my writing.

Maybe that will get better, maybe not. But one thing is for sure: the .NET scene has moved and I have not moved along with it. Time to slowly amend that.

Revisiting the Testing.Commons family

Testing.Commons family of projects (Commons, NUnit and ServiceStack) was written (more of distilled) quite a few years ago as a way to be able to reuse some of the techniques that I had used while testing the code me and my teams were writing.

It came in three flavors:

  • Commons: a collection of helpers that enabled writing slightly better tests in whichever testing framework being used. It included things like extensions and helpers to create dates, GUIDS, strings with a more expressive API, a non-committal way of writing object builders and some scaffolding to deal with testing logic involving localization, configuration and serialization. As well as defining a framework-independent way of defining testing constraints.

  • NUnit: enhancing NUnit with Custom Constraints that reflected my way of using (an abusing) NUnit’s Constraint Model to make tests more expressive and robust. Dates and collection assertions, composability of assertions, events and serialization.

  • ServiceStack: at the time, I wrote a fair amount of service using that framework and being able to write integration tests against them was quite a big thing, so I packed some of the plumbing to make it easier.

They were (past tense) .NET Framework projects even though I kind of got a glimpse of the future by dual targeting .NET Standard.

And then IT happenned

And by it I mean:

  • me not writing as much (or at all) .NET code
  • .NET Framework stopping being a thing, pretty much like .NET Standard
  • .NET Core or netcore or dotnet or .NET or… taking over
  • multi-platform for the masses and existing in a Windows-less (not completely free) world in which “sane” developers do not need to install Visual Studio to write C# and few remember IIS
  • me being older by the second

Oh, and the natural decay process that software projects suffer when more of life takes their place and the user base is slim and contributor base is slimmer.

And now?

Testing.Commons.ServiceStack does not make sense anymore (for me, anyway) and we can move on by seriously deprecating it.

The rest of the projects are no longer .NET Framework friendly. They target net6.0 only.

Quite a few features have been deprecated. Refer to the project Wiki for details.

The whole building process has been revamped and we see the CLI approach shine for automation.

C# muscle-memory has been regained and a crap-load of knowledge gained to catch up with the times.

The result?

Major versions (with loads of breaking changes) for Testing.Commons]( and Testing.Commons.NUnit

Static Badge

Static Badge

I will be writing about tooling and process in other posts.

Until then, keep up the joy.