3 min read

[Series] Your .Net Unit Tests Are Judging You: Why You Should Listen to them

I'll just do a little more manual regression testing...

Is unit testing (opens in a new tab) C# (opens in a new tab) code tedious or difficult? So tedious or difficult that you need to add many extra story points onto your current work item to overcome the behemoth task?

Are you contemplating running a few extra manual regression tests (opens in a new tab) and calling it a day because you have no conceivable way of writing automated tests for the current codebase?

Guess what. You're being judged!

Yes... of course I'm judging you.

Most importantly however, the function signature of your (yet to be attempted) test case is looking down on your code base with a savage side eye as you struggle to understand what on earth the existing tests actually do, inject dependencies, setup mocking (if at all), assert objective outputs from your code, and what knows what else.

But hey! This is existing code. You didn't make it this way. But can you make it better?

You're so Smart, It's Stupid!

Over the years I've seen many brilliant programmers write the most overcooked, tangled spaghetti code that is near impossible to test. Complexity in code does not equate to a brilliant mind or even an appropriate solution. A wholistic solution may itself be inherently complex, however, it can likely be built with many simple parts.

The life of a Code Sloth instills an aspiration to write the stupidestly simple code known to man (it's a Code Slothian word - go with it). Any graduate level engineer can write unintelligible code. It is a truly experienced engineer who can take a complex problem and compose a functional solution from simple components.

Simple code means simple tests which are simple to write and simple to maintain over time.

Just Because We Don't Like Spaghetti, it Doesn't Mean We Can't Have a Pasta Dinner

While poor quality tests pass judgement of Gordon Ramsay magnitude over your failed attempts at authoring simple code, they (much like Gordon) are trying to guide you down a better path. Unable to tell you in as many words though, the common pain points of testing spaghetti code each have specific strategies that can be used to completely remove the seemingly insurmountable obstacles that sit before you.

Well tested code forms documentation about how your system functions and fails. It mitigates accidental regressions, deodorizes nasty code smells and becomes your own personal chef that tells you your pasta has been cooked to al dente perfection.

This series will cover how you can untangle the legacy strands of spaghetti code cooked by your colleagues and plate them into a serving of simple code supported by a succulent suite of saucy tests that come topped with rich marinara and a side of crunchy garlic bread.

Enough talk, let's eat! I mean... Let's learn how to refactor and test!

Oh, and we'll also be launching some sloths into space in this series. Buckle up! ?

Sloth Summary: Unit Testing C# Series Posts

This series is now complete! Browse every post in the series cards below.

Series

More in this Test Refactoring series

[Test Refactoring Part 1] Introducing The Problem Code

Dot net core unit testing should be easy. Follow this series to learn simple steps to refactor legacy code into the stuff of unit testing dreams! ?

12 min

[Test Refactoring Part 2] Sticky Loops

Stuck trying to unit test logic in C# CancellationToken, or infinite loops? These simple steps will bring back determinism to your tests ?

14 min

[Test Refactoring Part 3] Concrete Dependencies

Learn how pruning concrete dependency trees from your code with C# abstraction super charges unit testability. Regain determinism with these simple steps today.

18 min

[Test Refactoring Part 4] Hidden Concrete Types

Learn how to overcome challenges of testing code with static dependencies. Discover strategies to refactor static code, introduce time provider abstractions, and handle manual delays for improved testability. Build more reliable software with comprehensive testing practices. Read more! ?

29 min

[Test Refactoring Part 5] Dependency Simplification

Wrap up the test refactoring series by simplifying dependencies into clean, testable abstractions.

18 min