Why I started writing tests — and other stories.

As a software developer, especially one with little experience, it’s very easy to get confused about what you should do and what you shouldn’t do.

There are tons of articles, written by way more experienced developers telling you which software development practice is an absolute taboo and which isn’t.

Some will tell you that TDD is the holy grail of software development and if you don’t write tests before you actually start writing the functionality of your application, you can’t possibly be a good developer.

What people fail to mention is that a lot of practices (including not writing tests) are only beneficial in certain situations. I’ll try to illustrate this with some examples;

• I’ve sometimes read articles about setting up a git workflow for adding features to a codebase. It’s easy to read some of these relatively complex set ups and feel bad for having something inadequate in comparison. But is it really inadequate? Not really, I’ve (mostly) been the sole BE developer for a lot of the projects I’ve worked on for clients and I’ve found that it doesn’t make sense to always make pull requests and force myself to go through hoops to merge my own feature. I mean, I’m the only developer working on the repository, I can commit and push as I like.
• Or you know how (in my experience, Nigerian) more experienced developers love to harp on about “building it from scratch”?. Yeah, totally build that not-at-all-custom authentication for your application every goddamn time because if you don’t, you’re not a good developer. Sometimes, there’s no time to build something from scratch and/or there’s no need to — especially as the open source tool you’re going to use is probably way better than what you were gonna build anyway.
• Even I am guilty of these things, I always playfully mock people who don’t use JetBrains IDEs. Like, “How can you possibly do any serious work with Sublime fucking Text?”. Well, different shortcuts and keystrokes for different folks.

Anyway, back to writing tests. I always felt like writing tests was a waste of time. I used to think “How can it make sense to write code that checks if your other code is working? That’s more potentially buggy code right there”.

And I used to feel bad sometimes, because I didn’t get it. Why did all the ninjas I admired feel like writing tests was the one true path to code Valhalla?

Well, in the end, as usual, the answer to the questions; “Should you write tests?”, “How should you write tests?”, “What should you test?” are very nuanced and dependent on exact use case.

Sometime last year I met Kent Beck and I asked him pretty much those questions. Kent told me that in the end, nobody pays for tests, they’re only necessary where you deem it so to give you a certain level of confidence about certain bits of code. And that there’ll always be a trade off between time and number of tests.

What does all that mean?

• Well, it means, given ample time, you should probably test the parts of your code that are likely to break or…
• If you’re the kind of person that prefers to use tests to define the functionality of your application because it makes you work faster, then go for it.
• Also, if you work for or aspire to work for an organization that prioritizes (certain kinds of) tests, then you should probably learn to do what they do.
• If your client isn’t paying you enough for the hours it requires to write tests, well…depends on how charitable you’re feeling.
• There’s no time? And you’re pretty much copying code that you’ve written before? Well, what are you testing for?

Bottomline, there are no definite answers. It depends on you and the situation(s) surrounding each project and any time t.

In the end, what we need to realize is that nobody pays for tests, they’re not the final product, they’re a means to an end.

Now I write tests when I feel like I should not as a rule — which is honestly A LOT more these days, but that’s because my inner software checklist has changed over time, my process has evolved and etc.

So go out there, and make software that works, however best you know how to.