I was not ready to TDD

By Nivedita Sood

18 Nov 2019

4 min read

It’s been more than 13 years I’ve spent writing software as an engineer. And I had always felt intimidated by the thought of writing tests before I wrote code that made those tests pass.

When I joined the React team at shaadi.com, everyone was already writing tests. But nobody was writing tests first. So I ended up joining them too and “wrote some tdds” from tech Dept. But all we were doing was writing tests after the development and not before starting the development.

All I wanted to do is ship code with confidence There was always an uneasiness I personally felt around the discipline of Test Driven Development but there was a similar gut feeling I had about the code I was shipping. For my team and I, it’s really important to ship the code that works, otherwise we might lose their trust and credibility.

To overcome this feeling of incompleteness in Tests , I decided to follow the standard way of doing TDD. I started writing the very first test with one of the new project on my plate.

When the head of frontend engineering at Shaadi, Amit Erandole, heard about it, he joined in and explained how the process should be. He walked me through the whole process and helped clarify the gaps and misunderstandings I had about TDD.

At the end of my first cycle, I had this fantastic realization:

TDD is not test-first. TDD is specify-first and test-last

That’s me realising what TDD really was — (I think I forgot to have lunch that day) 😅

The process is “Specify — Implement — Verify — Maintenance”. It’s just a waterfall model that loops very quickly (one cycle usually takes a couple of minutes).

Step 1: Specify

The first step in TDD is to write a test specification of the desired behaviour. Here you need to think about what the software/program should do, before thinking about how it should be implemented. You need to focus on just one thing at a time — separate the what from the how.

The specifications are documented in a very formal way. It communicates the developer’s intent to other developers and stakeholders, because anybody can have a look at the specification and see what the developer had in his mind when he will implement the feature.

Here is the example from my project [Customer-Satisfaction Survey]

https://videopress.com/v/oFjDaDOX?preloadContent=auto

Step 2: Implement — red, green cycle

After the specification has been written, it’s time to think about how to implement it, and then just implement it. You need to focus on passing just one tiny specification at a time. This is the most easy step in the whole TDD process.

You need to write your test code before your functional code. Write a single unit test, and then just enough production code to fulfill that test. Your mind needs to be trained to refuse to add even a single line of code until a test exists for it.

The TDD approach needs a great discipline because it is easy to “slip” and write functional code without first writing a new test.

Step 3: Verify

Now as you have implemented a couple of lines of code, you can verify that the code fulfills its specification.

Step 4: Refactor

Now that your tests are passing, you can make changes without worrying about breaking anything. Pause for a moment and look at the code you’ve written, and see if you can improve it. Look for duplication and other “code smells”. Improve the structure of the code to ease future changes and maintenance.