I’ll just do a little more manual regression testing…
Is unit testing C# 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 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! Check out all of the posts below:
- [Series] Your .Net Unit Tests Are Judging You: Why You Should Listen to them
- [Test Refactoring Part 1] Introducing The Problem Code
- [Test Refactoring Part 2] Sticky Loops
- [Test Refactoring Part 3] Concrete Dependencies
- [Test Refactoring Part 4] Hidden Concrete Types
- [Test Refactoring Part 5] Dependency Simplification
