Little things I would teach to my younger software engineer self - #5 Taking unit testing seriously

Looking back at the various stages of my career, I realized I could have learned some basic stuff way earlier than I did.
Even if I missed the original opportunity, all those little skills I acquired late served me tremendously well ever since.

2000-me: Common, I just need to be productive here: I code, try it a little bit, it looks good. Let's ship it!

2014-me: You are headed to a huuuge pain. After a regression during a bug fix for an initial regression you were just trying to fix for another bug on some horrible code you don't even dare to try to improve, you'll finally see the light and read:

Refactoring: Improving the Design of Existing Code by Martin Fowler

I had a huge code quality bump when I settled and consistently affirm that "Untested code is equivalent to broken code".

Initially, unit tests look like a huge waste of time but very quickly it will pay off:

1. It will give you some assurance that your code is at least working as intended. This will save you some exponential time on manual testing as you add complexity in the code base.

2. It will save you a huge deal of time when you gonna refactor or improve the code base.  The unit tests will tell you instantly what might have been impacted by your last change.

3. It will force you to write single-purpose modules or classes or functions. Once you start to bloat your code, you'll notice it quickly as it will become very hard to come up with a test for it.

Oh, and another tip before you go, when you'll see the light you might become a little bit over-enthusiastic about it. You'll see 100% of code coverage as the holy grail. But no, not really, the last 10% gonna be sooo painful to get and will not add anything quality wise. Test only ~80%-90% of the critical code you know is interesting to test.

Any tips you would give to your younger self programmer ? Feel free to comment below !

No comments:

Post a Comment