This post is part of two awesome advent calendar initiatives - the .NET Advent Calendar 2021, and the C# Advent Calendar 2021. Check out both links for awesome community blog posts!

There are quite a few different mocking libraries in .NET. Moq and NSubstitute seem to be by far the main ones I hear that developers use. I've used both of these in different projects, and really like them both. Whilst my preference leans towards NSubstitute, I'd be happy using either. Out of interest, I posted a Twitter poll to see what other people preferred, and the results and replies were really interesting!...

When writing tests, sometimes it can be tempting to dump a bunch of asserts into the same test to avoid duplication across multiple tests...

Following on from my post about why you should write automated tests, I wanted to talk about how to write code that is testable. Unfortunately, unless you explicitly know how to write testable code, and are familiar with the SOLID principles (which from my experience, the average developer isn't!) - then the natural way we write code, and the way we typically learn to code makes it very hard to write unit/integration tests against our code.

Over the past year or so I've been getting more and more interested in the various forms of automated testing. I've been a developer for verging on 20 years, and yet it's only been these past few years where I've seen a much larger interest in automated testing in the industry as a whole. It's obviously been around for a while, but it's never been as popular as it is today. Especially now the tools and libraries are getting better and better. In the past, it was a rare exception where a developer would heavily write tests as part of their code. Now, it's frowned upon if you don't.