Let’s me make things clear, I came from rails background, so what we call unit tests here is actually something that people often refer to as integration tests, meaning it does has a connection to the database and it does calls other classes. Another thing in which I do believe, that the way how to test is already better, than fully described in https://martinfowler.com/articles/practical-test-pyramid.html. Now that we’ve got that out of the way, let’s talk about why to test.

I’ve been working in companies with different philosophies about testing, and sometghing I would like to outline is that e2e test is cool, no doubt, but they are also heavy and brittle. It takes a lot of resources to run them, and it takes a lot of time to write/fix and understand them. It’s because they test the whole scenario, it’s not a viable strategy to run them all the time while development. Like you still need them, but not to be run often.

1. Proving code actually works

Once you’re done with your code, how do you prove that it works? You can test it manually, but what if you decide to slightly change it? Maybe rename constant used in multiple places, maybe re-arrange functions. Unit tests give you the possibility to just re-run them and ensure that your code is still working, it is still reachable, and still produces proper results. Also, you can refer to them as proof of implementation in future. In a couple of month when documentation for project is gone and jira tickets are purged or lost, you still have a test, which proves that the button is supposed to call pizza and not pasta.

2. Reading code

Let me be honest with you, as a developer, I hate writing documentation, I hate doing diagrams and writing post-mortems, writing code, whatever, for features or bugs are much more fun than retroactively writing documentation. Further more, if we would write documentation for every small feature we implement, we would have no time for shipping actual software, just constant .md files, which nobody reads. However, do I have a solution for you to this? You can always just read a unit test for the given feature. It will give you an understanding of why it works and how it works, while leaving the scope small enough that people don’t need to understand whole project. No, I am serious, you want to understand what code this function does? Read unit test.

Unit tests will also help you onboard new people, as they can just read tests and understand what is happening instead of going around fishing for knowledge.

3. Refactoring

Do you remember the last time you needed to refactor a function or class without changing behaviour? That’s where tests would 100% help you.

Want to refactor something? Sure, unit test gets you covered, just keep re-running it while you rewrite code. What do you say? While you are refactoring test keep breaking because you change code? That means you were testing wrong, you need to test behavior, your test doesn’t need to know the name of variables, structs, or anything, if your function were writing to the database, it’s still writing to the database, that’s not changing.

Don’t know how something works, but still need to change it? Add unit tests, they will cover you.

4. Covering errors

I think this one has already become a rule, but I prefer to say it outloud, just so there’s no confusion for it. I think every bug that you can cover with tests should be covered with tests. It will ensure that you:

1) actually understand the problem 2) actually fixed it 3) have a safeguard against regressions

When I have trouble falling asleep I usually watch some random stuff on YouTube (video games, tech stuff, whatever, tbh). Recently, during one of such nighttime sessions, I encountered a video of a dude, who decided to showcase building of a personal blog. He doesn’t speak much, uses NeoVim, and just planned to make a blog. I thought that’s cool, ASMR, but with NeoVim and typing. I was excited in the beginning, but I started feeling something fishy when he started installing React, typescript, and Astro.

That made me think, in many cases, we would overcomplicate things for the sake of complication and nothing more. We build skyscrapers in our software, start projects, which has more “micro”-services, than users, add React and GraphQL for a project, which just getting started. And don’t get me twisted React, GraphQL, and micro-services are all good use for a right project. If you’re a Facebook you do need GraphQL, if you are Netflix it’s on you to create a ChaosMonkey, but most of us neither.

I am a Ruby developer and as far as I remember there has always been an ongoing discussion if Ruby is performant enough for a proper web application. Should we replace it with Node? Elixir? Go? Rust? But the real question always was “Will we have enough customers, so, performance will become a problem for us?”. I’ve seen applications, which were big and small, with great and bad performance, and in many cases, it wasn’t Ruby, that stood in the way, no matter how fast is your programming language if you have no indexes in your SQL database, no matter how fast is your programming language if your GraphQL queries load thousand of unused objects along the way.

We all like code, that looks cool, which makes us feel like we are engineers for writing it, but it’s not necessary, that it will be with the same ease to support that code. At the end of the day, all I want to say is “Do not overcomplicate things”. Keep it stupid, simple.

Generally, I would be able to finish this topic right after this phrase. But, I believe, it will be honest if I follow my own advice and will do the hard thing.

I am writing this topic in January 2025, around 2 years into 6 months after which I will be replaced with AI. I remember in 2015, when I was still in university everybody was telling me that developers are about to be replaced with no-code. Lucky for me I only started doing code for money in 2018. And about that 6 months in previous 2 years, I had a job, get laid off and found a new job again.

At this moment you might ask yourself “What is this guy trying to say?”. I am saying, that you will be as good as you’re willing to actually do the hard things for you. How much are you willing to admit your mistakes and keep going. Try, fail and try again. If you will endure for long enough you will succeed. There are no shortcuts for learning, you need to do a hard thing -the one, which you don’t want to do - because that’s your learning point.

We are currently on the fast hype train of AI. “Developers will be replaced”, “people getting 50% more productive with Copilot”, “writing code is in the past”. This and many other slogans I hear everyday from every corner. And to be honest, I simply can’t understand them. People, who claim to be 20, 40, 50% more productive with LLMs look like either liars or on copium to me. A recent example of mine was with GitHub Copilot. I wanted to write a CI job, which checks changed files in PR, compares them with list of files from .rubocop_todo.yml (I am a Ruby developer, btw) and leaves a small comment, that maybe you would like to fix this offences, you change a files anyways. I spent quite a time explaining it what I want and still needed to write bash by myself.

And no, AI is not going to serve you as a fast train to success. If you just stop learning and will be just prompting you will be as good as AI allows you, but if you keep learning you will be able to be better and still receive help from it. At the end of the day you are just as good as your training.