My Name is Dave, and I Delete my Tests
At this very moment the current trends on Twitter are Ross County football club gaining promotion to Scotland’s premiere league, some nonsense about The Apprentice and here I am thinking about my tests.
Depressing as it sounds, it’s a common affair. Writing tests for my code is a not so guilty pleasure of mine, certainly on a par with sliding the unlock on the iPhone to listen to Lionel Richie.
As a newb I wrote tests to ensure my code worked. That concept is wrong but hey at least I was testing my code. I gained knowledge in the domain, and I ticked that mental box of “I’m a good developer who writes tests”. As I progressed I grew almost tight fisted with my tests. I wrote tests first, driving the implementation one fail at a time. At this level, tests were to aid refactoring. And that is a pretty big deal.
However, about the same time I started to look into other peoples takes on the process of testing and practicing TDD. I started to hear things like “Don’t hit the database”, “Don’t test Rails”. I have even vocalised “I don’t need to test that, Active Record is well tested”. I actually don’t have a clue if it is well tested or not but still, that was the stance I took.
All those statements are true to a point. I want fast tests that are isolated and insulated from third party code, which BTW I assume is well tested in the unspoken code of honor with my fellow developers. I still felt I lost something. For a while I wouldn’t dare write a line of business logic without a failing test in existence. Sounds good practice and it is, the problem was I maybe didn’t understand the domain, or even be familiar with the technology or framework.
I recently started learning the awesome Backbone.js MVC framework. I stalled at the first hurdle, that todo list. I became frustrated with myself as I couldn’t get my TDD hat on. No fault of Backbone or Jasmine, I simply didn’t understand the framework or the tools. After some spiteful contemplation regarding my abandoned todo list, I had a light bulb.
I was ranting to myself, “None of these tutorials touch TDD with Jamine!” and true as that was, I began to realise why. TDD is not important when learning a framework. TDD doesn’t matter when spiking a new problem. TDD just didn’t matter. It gave me no value in this scenario. I extracted the project from my morgue directory and stared creating, being productive and most importantly learning, without tests. It was brilliant.
With the knowledge of the tools at hand, I could start writing tests that fulfilled the domain. But the previous example clearly shows a scenario when tests are of no value. In fact, they were detrimental. In that first few hours I wrote no implementation code because I spent so long trying to get my damn tests to work.
That in turn has led me to another burden for my passing TDD thoughts. Value. Now not only do I have to think about making the test fast, isolated and insulated. I also have to ensure it yields value. And I’m now thinking value for me is the most important component. My tests can take hours to run for all I care, as long as they are deemed valuable.
I didn’t understand Active Record scopes. I could think of only one way to test them, put some data in the database and call the scope. That single test broke two of my rules about writing tests. It hits the database and partially exercises framework code (scopes work). The alternative was to just write the scope and cross my fingers it worked. But I gained so much value from these tests, I now understood scopes.
Returning to the title of this article, do these scope tests still exist in my code base. No. They were committed, pushed and duly deleted. The value of the test had been reaped, but factors like insulation and speed remain in the code base. And what happens if I see the need for a new, sightly complex scope? I write a test in which I hit the database and exercise the framework code till I hit green. Refactor. Commit. Strike that little key up there next to ‘Home’. And not once have I felt guilt in doing so.
