Unit Testing through out my career

When I started my career as a Software Engineer. I remembered very clearly I was taught how to cover each and every possible conditions of my source code. It was not automated back then, but it did help me ensure I am delivering code as I intend to deliver them.

As my career progress, automated unit tesing because a standard, and for some reason code coverage became a thing. This was at a point where I am working at a much senior capacity, and I recalled clearly the negative impact of this code coverage to developers. I saw unit tests hitting every simple if statements and properties for the sake of hitting them. I hated this as vowed to do everything I can to make sure this does not happen again.

With the popularity of Test Driven Design (TDD), I immediately jump at the chance to apply it on my projects. I believed having the end result in mind would help me build better software and would not need to worry the code coverage requirement, as it would come naturally. Making sure I only built what I have in mind, ensure I would hit every single code I planned to build and nothing more. Don't get me wrong, I did not write test first, and see them fail, and write the code. I basically wrote the test and write the code to make sure the test passed. It might not be for everyone, but it does work for me.

But still, updating code results to breaking tests. Then, I'll have to recall why I did what I did. It seems like I could not remember the piece of code I've written a week ago, let alone the unit tests that comes with it. Maintaining the tests became a nightmare, and getting more and more troublesome. And let's face it, if a tight deadline is in play the first thing to be compromised are the unit test.

After all these years, I am wondering how would unit test really help me. Recently, I've applied a different set of thinking on the way I've done unit tests. I'm writting unit test to safeguard against future me. I wrote unit test to reflect what I intend the class to do and to make sure I don't update it to something I would not want it to do. I'm still thinking on the TDD mindset, but I focus more on what I intend the class' responsibility are and what should not be added to it's responsibility later on.

For example:

public class CarFactory{
    public Car Create(CarType carType)
    {
        ...
    } 
}

In the above example, I design my factory class to create cars but I am not intending it to produce anything else. If I want to create a boat, my intention is to introduce another factory (BoatFactory). So, I'll write unit tests to ensure it does produce a car, based on carType. But, I'll also add an additional test to make sure any of it's public method should not produce anything else. This way, I'll make sure I won't break the design I defined now. And if I do, there is a conscious decision of doing it then.

I know this post might not be for everyone, but I hope it does spark some idea into somebody brilliant. c",)