From crappy to happy - refactoring untestable code - an introduction

I started testing my code automatically a couple of years in after starting my career. Working in a small company, there weren't really incentives for us to automate testing and we were not following any kind of best practices. Our way of working was to write the code, test it manually and then just Release It ™, preferably on a Friday of course.

I'm sure everyone can relate to this at some point in their career, because this is a lot more common than the Almighty Programming Gods of the Internet make us believe. I find that the amount of companies that actually bother writing tests for their production code is a fraction of the whole universe. I know some friends who work in pretty big companies with big names in the industry and even there the same mindset exists.

Of course, at some point in time our code turned into a big pile of shit. Nobody really knew what was going on and where. We had quantum-level switcheroo that nobody really wanted to touch, and I suspect it is still being maintained today. We were a C# shop, but finding where logic happened was as difficult as untangling the worst kinds of Javascript crap. I'm sure I'm not alone in this one too :)

Young me had never heard of such thing as automating your tests. It was truly a whole new world that I was about to discover, and oh boy what a ride. Before long I was neck deep into the concept of unit testing, integration testing, end-to-end testing, fakes, mocks, stubs and anything in between. It was a really eye-opening time for me and eventually I fell in love with the concept. The simple idea that you can prove your code works and prevent it from breaking in the future is p o w e r f u l. 

And so I went deep into the concepts of TDD and started practicing it, read a lot of books on the subject (the classics), bought an edition of the Gang of Four (Design Patterns: Elements of Reusable Object-Oriented Software), discovered Martin Fowler and Uncle Bob and other great architects and coders... I learned so much in that rush. But then came reality:

It is so much more complicated than having these concepts in a book and reading about them, or trying them in your Useless App #69. Here are some problems I struggled with the first time I tried to apply the concepts:

1. Lack of understanding. It is one thing to read it in the book and see some minimalist examples in a well isolated harness. It is a different thing when you try to pull apart a 3500 LOC code-behind in a C# Windows Form application. That is an uphill battle.
2. Testing can become impossible and counter productive if your project is not designed with it in mind. Ours wasn't. 
3. You can't look at "testing" in isolation. It brings so many concepts attached that before long you will be overwhelmed with so much stuff.
4. You can't just pick up code that possibly works and start changing it. There is a big deal of risk involved. This requires buy-in from management and understanding that things can go wrong.
5. Testing is an investment. I can't stress this enough. It is not something you will get rewarded from applying right away, although there are some immediate benefits. It is something that might take months, even years, to give you good returns. It is more noticeable when someone new enters the team, or someone knowledgeable leaves. Tests are good artifacts that someone leaves behind and that can help document their work. They are the good legacy code.

About point 3, here are some examples of things you need to understand if you are starting from 0 as I was:

• The concept of testing and the multiple kinds of tests you can do
• What to test? What is a testable behavior?
• Know a framework that allows for unit testing (NUnit, xUnit, MsTest)
• What are fakes, mocks and stubs?
• Learn a framework that allows you to create those fakes, or apply techniques that get you the same behavior.
• How do you structure your tests? 
• Study hard about design patterns, know when to apply and which situations. Know the SOLID principles closely.

Did you notice that I did not include anything about the code itself? If you already have code, then you also need to:

• Introduce meaningful abstractions and layers that create a better separation of concerns. This might mean having to learn MVP, MVC or MVVM, for example.
• Start identifying and pulling apart dependencies in your code. 
• Apply dependency injection and inversion of control everywhere.
• Preferably introduce a dependency injection framework and know how the hell it works. Then learn how you should structure your test code to play well with that DI framework, or ignore it altogether in the tests and do the wiring manually.
• Check any dependencies that you have (eg: EF) and find out how you can test those or whether you need to abstract them away into their own layers.

These are just some of the most obvious ones. Notice that this list has it all: behavior changes, architectural changes, a myriad of new things to learn about... It truly becomes a mess.

Having said that, learning automated tests is also one of the most wonderful things you can do for your career:

• After learning all this (and still learning many years later) I can say that I truly boosted my knowledge of how you build software. In wanting to learn "testing" I ended up having to learn a lot more than that. There is no other way around it, but it truly rewards you.
• In general, you will be more valued as a software developer if you know your way with testing because in the wild it is a rarer skill.
• When you have practice in writing testable systems, it is natural that you also have practice detecting anti-patterns that break testing. Sometimes the smallest things matter and will break a good test suite - looking at you, DateTime.Now.
• You will naturally get acquainted with the concepts of CI/CD once you introduce automated tests. This can be a good skill to have.

Putting myself back in the position I was initially, one of the problems I had was that many examples assumed that I was working with new code that I was writing (yes, I know the Refactoring book).

So, I will start a series of posts that try to emulate situations from the real world, introduce some example refactoring and finally explain the theory behind it in simple terms. Sometimes there are simple things we can do while refactoring, but people will shy away from them because they have fancy names, so I think we will start with Dependency Injection!