TDD and my relationship with the debugger

Oh wait, first of all, I did not wake up today to write this blog post. This blog post results from an accidental discovery I made when exploring my IDE for no particular reason.

Folks that practice TDD (including its pioneer Kent Beck) have mentioned that their debugger usage has gone down drastically. You'd probably hear people saying either that or things like, "I don't know the shortcuts for the debugger."

I don't know about you, but qualitatively, I have seen my debugger usage going down steadily and significantly over the past five years. As a side-effect, the only keyboard shortcuts related to the debugger that I know are ⌘ + D (Debug) and ⌘ + ⇧ + D (Debug this).

So, now why does this matter? Before we get into that, let me show you what I stumbled upon today.

The Screenshot shows the tool window of the Key Promoter X plugin. For those who aren't familiar with Key Promoter X, it is a plugin that tracks your actions inside IntelliJ and nudges you to use shortcuts for frequently used actions in your workflow instead of the mouse.

Now, I didn't know that the plugin collected statistics about the usage of these actions. I have highlighted the actions that matter for our discussion in the Screenshot. The first shortcut is ⌃ + ⇧ + R (Run this), and the second shortcut is ⌃ + ⇧ + D (Debug this).

These shortcuts differ slightly from ⌃ + R (Run) and ⌃ + D (Debug). Typically devs use Run and Debug to execute large portions of the application, usually the entire application (unless they have multiple entry points or run configurations).

For those who write tests, you may want to run either a single test, a part of the test suite, or the entire test suite, depending on the changes you make to the code base. That's where Run this or Debug this comes in handy.

I don't know why Key Promoter X does not show stats for the regular Run or Debug actions but let's look into what we've got. It might show you some insight into my workflow while I build software. (Technically, Run and Debug will run your current configuration, but I don't want to get into the details for simplicity's sake).

Hardware and software

1. I bought this Mac sometime in December 2020, so I have owned this for a little over a year.
2. I use IntelliJ IDEA Ultimate for my development apart from Android Studio. I wasn't a fan of Key Promoter X (IMO, less effective) and stuck with the good old Key Promoter for a very long time. However, I must have had this plugin installed for 8—10 months.

Crunching the numbers

There isn't a lot of crunching, and most of you wouldn't consider this crunching at all. According to the plugin, I have used the Run this action 4,985 times and Debug this action 68 times. It means I verified the changes I made to the codebases either wholly or partially 5,053 times ever since I installed the plugin. This number is without taking into account the Debug and Run actions.

This number may seem like a lot (or less depending on your workflow), but I don't have a baseline to compare. However, almost all of my contributions in the past year are on GitHub, and most of them are commits. When I checked my contributions last year, I had almost ~3,000. Of which the majority are commits, upwards of 95%. I can find the breakdown of these because I use conventional commits and can use a tool to go through all the history from these repositories, but we are not going down that rabbit hole yet.

The other thing that could be helpful is the nature of my workflow itself; I tend to commit one behavior at a time, consisting of at least two runs in the TDD workflow. One for the red and one for the green. I also run my tests when I refactor. I also run the application often when working on the UI/command-line interface. I don't usually write tests for the UI because they have pretty low ROI. Considering my workflow, I have had at least run my programs 5,053 times is quite conservative (because we don't have the stats for Run and Debug actions). But it is feasible when comparing them against my GitHub contribution history.

So, we know from doing a little bit of elementary math that I use the debugger in my TDD workflow 1.34% of the time (68 times of 5,053). So, if these numbers are what they are, folks would now understand how fast feedback cycles look like and how TDD can help you ship fewer bugs and also high-quality software in a short period. It's not magic; make as many mistakes as quickly as possible and fix them before other folks see them.

So what?

Nothing, I was baffled at these numbers and wanted to put this on the internet and document it for my own sake.

Are these numbers even correct?

I don't know; I don't know how Key Promoter X captures these numbers. But what I am curious about is why the plugin does not capture my other shortcuts. FYI, I use more than 55 shortcuts. How do I know? I created macros on a separate layer on my Keyboard, and all my shortcuts are now literally one keypress away.

Should I practice TDD?

Maybe, I will not tell you what you should or shouldn't do. For all that I know, TDD works for me under particular conditions, and it is a lot more nuanced than what I used to believe. At least until last year, my stance was that it takes the same amount of time to ship software with or without TDD, but recently, I uncovered evidence that it is not so simple. For me, it takes longer to ship software without TDD, but that's just me. Factors such as programming paradigm, planning, breaking down the problem, patterns you use, typing, familiarity with IDE features and shortcuts, architecture, build times of your codebase all play a significant role in deciding how you experience TDD. Taking this further, TDD itself has two different camps—outside-in and inside-out, and both have their applications and will result in various designs.

However, if you choose to give TDD a try, do it as a group or participate in code retreats. You could also pair with someone who already does TDD. If you decide to do this independently, it would be a difficult path to travel and probably won't help you see its underlying beauty.