pixxelkick , 5 months ago

I despise the current paradigm of mock’ing everything, abstracting everything, and unit testing 100% cide coverage for no logical reason.

Instead I only unit test the following:

1. Any code I truly want to unit test, because it does something that is iffy on if it works or not, I break out into atomic logic that can very easily unit test.
2. Code coverage is a business requirement and we already have 100% coverage from integration tests, then I’ll start worrying about unit testing the shit out of stuff.

In other words if you waste time on mindless unit tests to assert that 1+1=2 when you dont have 100% coverage on your integration tests yet, you are wasting time.

In terms of atomic code, consider this example:

<span style="color:#323232;">public class StudentService(IStudentRepository repo)
</span><span style="color:#323232;">{
</span><span style="color:#323232;">
</span><span style="color:#323232;">    public bool AnyGrade12()
</span><span style="color:#323232;">    {
</span><span style="color:#323232;">        var students = repo.GetStudents();
</span><span style="color:#323232;">        return students.Any(s => s.Grade == 12);
</span><span style="color:#323232;">    }
</span><span style="color:#323232;">}
</span>

This would be very normal as a pattern to see, but I hate it because to test it, now I need to mock a stubbed in IStudentRepository.

Consider this instead:

<span style="color:#323232;">public static class StudentService
</span><span style="color:#323232;">{
</span><span style="color:#323232;">
</span><span style="color:#323232;">    public static bool AnyGrade12(IEnumerable students)
</span><span style="color:#323232;">    {
</span><span style="color:#323232;">        return students.Any(s => s.Grade == 12);
</span><span style="color:#323232;">    }
</span><span style="color:#323232;">}
</span>

Now this is what I consider atomic logic. The rule of thumb is, if the class has no dependencies or all it’s dependencies are atomic, it too is atomic.

Generally it becomes clear all the atomic logic can just be declared as static classes pain-free, and there’s no need to abstract it. It’s trivial to unit test, and you don’t have to mock anything.

Any remaining non-atomic code should end up as anything you simply must integration test against (3rd party api calls, database queries, that sort of stuff)

You’ll also often find many of your atomic functions naturally and smoothly slot into becoming just extension functions.

This approach goes very much against the grain of every dotnet team I’ve worked with, but once I started demoing how it works and they saw how my unit tests became much less convoluted while still hitting ~90% code coverage, some folks started to get on board with the paradigm.