I enjoy writing tests

Why? Because they help me implement features faster.

But it wasn’t always that way. Let me show you how I went from aversion to actually enjoying tests, and why they’re so helpful now.

Bad experience

My first experience with tests was awful. Back in 2015, I worked on a team that had strict code coverage requirements. The workflow looked like this:

They didn’t have integration tests; unit tests were mostly trivial, with tons of manually initialized mocks.

Any test tried to assert every available property, so any small change broke dozens of tests. Tests were seen as a pointless burden that wasted time.

Nonetheless, I didn’t give up on them because of the confidence they provide and the automation of checks after every small change. I read, practiced, and found out that tests — when done right — can be both helpful and enjoyable.

Let me illustrate how this is possible.

Life without tests

Imagine a dealer system that sends purchase orders to a vendor. You have item prices in your ERP, but the actual price might differ, and you want to decide whether to place an order if the price is lower or higher. You have user preferences stored somewhere, and you’re writing code to handle price discrepancies.

To check if the logic is correct, you might:

1. Create a dummy order in your local ERP (set up beforehand),
2. Run your app,
3. Find that order and start the order-placing process,
4. Let the app load a bunch of data from the ERP’s database,
5. Have the app call the vendor’s API to get actual prices,
6. Override prices in code to create specific conditions,
7. Finally, stop at a breakpoint and see what happens for just one scenario.

But you have a lot of scenarios, even for this simple case:

A bug could cost money, hurt the company’s reputation, or both. You probably want to check at least a few out of these ten scenarios, which means repeating those steps multiple times. It’s tedious!

How life is getting better with tests

What if you could set up any context you want, without calling unstable APIs or monstrous enterprise systems, and without all those clicks and steps?

Tests give you that.

Once you define the context for a unit or subsystem, any debugging, troubleshooting, or experimenting happens instantly — just run the test, and you’re in your code. Compared to manual debugging and self-testing, tests are way more exciting; they make you productive from the start, even before you commit your code.

After confirming everything works, you add some assertions, verify that tests pass, and… are you ready to commit? Not yet. You better refactor your code (the first working version is usually far from elegant). Without tests, you’d have to repeat all the manual steps again, and your enthusiasm would hit zero.

Congrats, you’ve unlocked a workflow that leads to fewer bugs and better code!

A better way of thinking

Stop viewing tests as some burden just to please your lead or coverage stats.

Think of tests as another tool that makes your job more productive and enjoyable.

Nobody likes repetitive actions to reach the right state, or revisiting code to fix bugs found later by testers — or worse, by users.

Considering tests, think of how they can help you to spend less time troubleshooting, debugging, or frantically investigating surprise bugs two hours before a demo.

Sometimes they help in unexpected ways. Once I asked my IDE to clean up unused using directives, and suddenly several tests failed. I was surprised, but the failure was legit: the cleanup removed some using statements from my Razor (HTML + C#) email template code, so the template engine couldn’t build valid HTML. I certainly didn’t expect a minor cleanup to break email reporting — but tests saved me from a stressful production fix.

Pitfalls

Nothing in life is free, and neither are tests. Yes, defining context can be harder than just running the app. Tests can require maintenance, or be forgotten and become stale and useless.

I’ll address these concerns in later articles.

For now, I just want to emphasize a different way of thinking about automated tests: they are your immediate helpers:

This idea isn’t fresh from the oven. I wrote about it in my old testing best practices article, but it:

• was a long time ago,
• had too many ideas in one place,
• was heavily edited and lost my personality,
• doesn’t cover how modern LLM-era tools can help,

so I’m evolving those thoughts here in my personal blog. If you’re curious where I’m headed, feel free to check out that article now.

Agree? Not convinced? Let’s have a chat!