I Actually Enjoy Writing Tests

Yes, you read that right. I really enjoy writing tests for my code. While I am not exactly implementing the concept of TDD (Test Driven Development) while developing a project, I am following a strict rule for my own code:

Never push untested code

In this blog post, I want to write a little about why I enjoy writing test cases and how I do it.

Why Writing Tests Is Enjoyable to Me

A Good Weapon Against Doubt

It might be a hot take, but I think there is a connection between your general confidence in yourself as a person and your feeling towards writing tests. In general, I am very skeptical and rather not confident. I would categorize myself as a classic overthinker, constantly questioning if the thing I am currently doing is the right approach or thing to do.

Of course, this also transitions into my professional work and, therefore, the code I am writing. This is why I really like writing tests. It is a kind of proof that the feature I just developed actually works like it is supposed to. It is a constant proof to myself that I have successfully implemented the feature requested.

With tests backing up my code, I can explain it more confidently to my boss or customers. I can sleep better and be more relaxed knowing that my code is mostly stable. Every time I change something in my code, I just run the tests to be sure that I detect breaking changes. For me, writing tests makes my everyday coding life way less stressful and enables me to be less stressed and worried outside of my professional life.

A Way to Fuel My Logical Thinking and Creativity

Another thing I recognized while writing tests is that during the process, new edge cases pop up in my head that I hadn't thought about while actually writing the first bit of code. Thinking about what could potentially go wrong fuels my creativity and logical thinking. Oftentimes, I think it's clear what to do or where to click in this particular section of the website or app. But this is because I actually developed this section.

A user who is completely new to this website or app can do a lot of unexpected things. Every time I write tests, I try to think like a new user who just randomly clicks or writes stuff into text fields. This way, I am able to cover more edge cases and provide specific error messages that are easy to understand for users.

This ultimately makes my code and, therefore, my website or application better for the user. A win-win situation.

My Workflow - Why No TDD

Test Driven Development

I think mostly everyone who codes knows the term Test Driven Development. The concept is to write tests first, run them so they fail, and then write the code to make the tests pass. The goal is to constantly switch the test state from red (failing) to green (passing) by writing new tests or enriching the tests to cover more functionality, then writing the code afterwards. Each step is ideally just a few lines of code.

My "Problem" with TDD & How I Do It

Before I talk about why I do not write my tests before I start coding, I’d like to emphasize that this is just my personal opinion, and it may change in the future. I know that testing philosophy is a very sensitive topic, and I highly encourage everyone to research and find the best approach for themselves. The most important thing here is to actually write tests to have your code tested.

With that being said, I often find that the baby step approach used in TDD breaks my focus. When I have an idea, I want to translate it to code immediately. I want to "get my hands dirty" and get it done. So I simply start writing the first piece of code. While I do this and get into a state of focus, I stumble over another problem in the implementation but immediately know how to solve it, so I add the functionality straight away.

After a few minutes or sometimes even hours of coding, I have a relatively good working piece of code or functionality (at least it looks like it - I do not have any proof yet because I have not implemented tests yet). Once I reach this state where I am out of ideas or my state of focus is over and I get distracted, I start writing tests to prove that the code is really working. Writing the tests also uses up a lot of brain energy for me, as I explained in the first chapter.

For me personally, this technique works way better than TDD. This way, I do not need to switch between files and, more importantly, between my two states of mind: "being an inexperienced user" and "being a developer." I am much faster implementing code like this. However, it's been a while since I last tried TDD, and I may give it a try in the next project or feature again with my newly gained knowledge and experience.

Never Push Untested Code

One rule that I made for myself is "never push untested code." This means that before pushing a feature, even if I am very confident with the code and tested it a lot manually, I do not push the code before I have written at least a few tests for the most common use- and edge cases.

While writing these tests, I often come up with new edge cases that I haven’t covered in my code yet. This rule has proven very valuable for me in my first year as a professional web developer.

But the Feature Is Working and There Is a Deadline

Some of you might think that, in reality, this is relatively hard to realize. Most days, you have pushy PMs that want to deliver stuff fast and before the deadline. However, there are two things you should keep in mind.

When someone asks you for an estimate, you should always add a portion of the time for writing tests. If you haven’t accounted for the time it takes to write the tests and only estimated the time for the feature, then you are in no good situation.

I found it helpful to take some time and explain to my PM how my workflow is and that there will always be a little time I need to write tests, even if the feature is theoretically finished. After a couple of weeks of repeating myself and explaining how important tests are, my PM understood it.

Some may also suggest merging after a little manual testing and just writing the tests later. Let’s be honest. You will not do that unless something breaks. It is exactly the same with every piece of code most of us say they will improve later. Chances are very high that this is never going to happen because there is always something else, more important, to do. Just do yourself a favor and avoid this trap.

How I Structure My Test Cases

The way I structure or write my test cases is simple. I start with the "happy path" and then work my way through all the edge cases from most "likely to occur" to "very rare." Most of the time, while writing the tests, I come up with other scenarios on what could go wrong.

When I haven’t implemented these scenarios in my code yet, I indeed follow the TDD approach for this piece of code: first finish writing the test case for this scenario, run the test, let it fail, implement the missing piece of code, run the test again, and hopefully, it passes.

As you see, there is nothing really special about how I write or structure the test cases. However, I like to mock most of the dependencies to ensure the particular function or piece of code is really tested in isolation. This is because I want to eliminate external error sources that lead to false assumptions about where a potential error could come from.

Conclusion

I like writing tests because tests provide proof that my code is working and thus my confidence in meetings with users, customers, or my boss is higher when presenting something. Tests are some kind of security for myself and a good blocker for self-doubt.

I always write tests, even for the simplest functions, just because I really want this habit to stick with me. Some may also say that I write too many tests, but at the end of the day, it is usually a very individual perspective of what "enough" testing looks like.

I would suggest writing as many or as few tests as you need to feel confident about your code. The main thing here is to get in the habit of testing your code because it can save you a lot of trouble—not just in the near future, but also in the long run. See you next time.

Happy coding!