We should (waste time writing automated unit tests and documenting our code) as professional developers

If you have been programming for a while, you may know that experienced professional programmers put a lot of emphasis on unit testing, that's when they write code that tests the code itself. Testing the individual units of their code to prove that the code works like is supposed to, is a big part of their job. That's why that type of programmer is so valued and good at their craft. Let's talk about why we don't unit test or document our code and why we should do it.

Why we do not unit test our code?

• Takes too much effort. As programmers we have too much on our plate with little time, when we write code we feel comfortable at the moment, not worrying about the future or coming back to that same code that we wrote. We might feel like we don't move fast enough, pressuring ourselves to deliver new features, so we just jump into the implementation part to ship as fast as possible, skipping the unit tests part because it might feel like it takes way too much upfront effort.

• Bad Habits. Teaching how to do testing is not a topic well explained by instructors because it isn't interesting or fun, so from the start, we don't learn how to do it and we get in the bad habit of ignoring it completely.

• Is boring. Doing unit testing might feel like one of the most tedious, boring, and repetitive tasks, so it becomes a big burden that we avoid dealing with.

Why we do not document our code?

It's not a requirement, is something that is not needed and that it will not make our code better, so we might feel like is not part of our job, and if we do it we would be wasting time, we all think that our code is the documentation.

Why we should unit test our code?

Writing tests is easy, everybody already does that even though they may not have automated tests written. When you write a function that prints "Hello World!" in the console, you typically run your code and go to the console to see if it prints the desired output, that's manual testing.

We might write some code now and understand everything we did at the moment, but you might come back to that code later, tomorrow or in a couple of hours, and for sure we will have no clue about what we did, we will forget, so we have to go line by line all over again, doing manual testing just to figure it out or to add some new feature, so instead of doing it manually, we should automate that process with something that we already know, code, that way we can just run our tests in seconds and be sure that our code works like is supposed to, allowing us to move super fast by saving time.

Why do we need documentation?

Well-written tests are not enough because naming things and being as descriptive as possible is one of the hardest things that everybody struggles with, so documenting every detail will help us to maintain our code.

Conclusion

I know is hard and nobody wants to do it because of the huge upfront effort needed, but the more you do it, and the more experienced you get the more that you will appreciate it. The future payoff will be priceless, it will allow us to get back to that old code that we wrote and be up to speed in no time, adding that new feature, fixing a bug, or making sure that everything works like is supposed to.

Thank you so much for your time!

If you have any questions or need help with your codebase unit tests, let's talk.