A couple of months back, I completed my first software engineering internship at SeaLadder (www.sealadder.com), an early-stage startup, building a platform to help people find and acquire skills they need to achieve their professional goals in today’s age of information – with an abundance of high-quality and low-cost educational resources available right at our fingertips. It was an incredible growth experience for me, to say the least.
While there were countless valuable learning outcomes I had throughout my time as an intern, I can say without a doubt that the most profound one of these would have to be adopting the practice of Test-Driven Development (TDD) during software development, a method which my manager and founder of the company, Adam Pond (https://www.linkedin.com/in/adam-pond-0141705/) strongly insisted on using. If you are not already familiar with this term, it is in simple terms the practice of designing and writing test cases before going ahead to write and debug/refactor code.
Typical TDD Workflow
As the image above depicts, TDD sure does look deceptively simple on the surface:
- Write a test that fails.
- Write the bare minimum code to make the test pass.
- Refactor and clean up code before committing.
However, just because it is simple, doesn’t mean it is easy.
I struggled from day one to practice it, constantly cheating by going back to writing code first. I could not rewire my brain to think of the tests first, I mean, there was nothing to test! All the hours I had spent before – completing university assignments in haphazard ways, only made the situation that little bit worse.
However, I stuck to it. At first, it took me an awfully long time to produce any useful test cases, while my time spent coding remained mostly the same. However, in all my subsequent efforts, I could see that as I was getting better and faster at creatively coming up with the right tests in each situation, my development time went down, and my code quality went up drastically. It was magic.
With great encouragement and support from Adam and further grit and perseverance from my side over a period of a couple of weeks, I had become quite proficient in practising TDD. The benefits of TDD which everyone talks about today had made themselves quite apparent to me.
Benefits I noticed
Not only was I producing higher quality code, but now I was also laser-focused on the functionality I had to achieve. All I had to do was make the test pass! The added focus significantly increased my productivity.
The incredibly fast feedback loop that TDD provides, in terms of its “Break it, then Fix it” approach, gamified the process of software development for me, and I was slowly but surely, hooked to making sure my tests passed as fast as possible.
I was also a lot more aware of all the edge cases that existed in any feature I was trying to develop, which made sure that the code I was producing had a lot fewer voids and gaps that could make themselves visible. I realised that quality development happens at the edge cases and not at the average use case.
Takeaway
All the other benefits I noticed alongside the ones I have already stated (such as tidier and cleaner code, lesser time spent debugging, more maintainable and SOLID code), were more than enough to solidify TDD as a powerful weapon in my software engineering arsenal – a practice I would recommend all incoming and current software interns, graduates and developers in the industry to try out if you have been unaware of it or hesitant to use it in the past.
I’m certain that the mental excruciation it will put you through initially will be more than outweighed by the value it can offer to you and your career as a software professional in the near future.