It's a Thursday night and you've decided to commit fraud by not coming to work tomorrow. A nice piece of code is forming in your IDE, maybe something you would call an "algorithm" because of its complexity (contrary to dictionary definition of "algorithm")? While working on a SUBROUTINE, a stray sunray hits and causes a glitch... No, not in your CPU, in your brain. You suddenly think - why the fcuk do I have so many interfaces in my project? I don't even use them.

.NET doesn't support native mocking

Moq? NSubstitute? FakeItEasy? All wrappers around Castle.Core.DynamicProxy, a library that allows you to build an intercepting class object in between a virtual member and the actual implementation. The actual implementation is still there, its just never called. Have you ever tried mocking a plain old class? You get an error, because DynamicProxy cannot implement an implementation, and there is no way to create an interface because your tests are bound to the real implementation.

You shouldn't make sacrifices in your code to appeal to tests, let alone the testing infrastructure. It's not really what you would call boilerplate code either, you interact with it all the time, you need to register the class together with the interface in DI too in case you are writing something higher up above unit tests.

It's the same cancer that everyone does, but do not understand or ignore why they do it. It's the same as with AutoMapper or Mediatr (thank dog they got enshittified, at least a little bit), except of course here with tests you often don't really have a choice, unless you want to starve instead of eating a big steak.

Interceptors

Now that's a native feature that I could get behind, but as far as I see, it supports interceptions in a specific line of code in a specific file, and all of that needs to be hardcoded. Even if you could get them to find methods you want to intercept, you will be intercepting a method globally in the whole assembly. It would either mean that we would need to run tests one by one in a single thread, or group tests by identical mocked class implementations, load multiple main project assemblies as many times as there are groups, and then target different tests to different loaded assemblies.

Harmony based projects

Like MockMe, ZeroMock, others... Exist and they do work, but as far as I see, they need a lot of work to support various C# features, variety of class implementation scenarios, modifiers, etc.

But uhmmmm.. mocking is bad! and your FUNCTIONS must be pure!!

shut yo mouth. not everyone has a folder of projects where each of them is a parser of some binary format. When you're interacting with some complex system or device, mocking is inevitable.

The solution

Paid solutions don't count because generally people aren't bat shit insane to pay $599 for a testing infrastructure detail in a personal project.

Remove all interfaces, feel the pain (but not as far so you end up in a hospital) and complain to persons at microsoft that do not smoke Aium but maybe are only affected by second hand smoke. There should be facilities in .NET to support mocking natively, accounting for all of its infinite sugar syntax.

Oh and make your methods private too instead of internal or public. Remove that ugly ass hack that is InternalsVisibleTo. You shouldn't make any sacrifices at all in your project code just to conform to some test infrastructure deficiency. Tests should be able to call private methods, because tests do not run in users system, so what tests do don't matter.