I used to think writing unit tests, E2E tests, and maintaining a proper testing suite was unnecessary for most projects.
If developers write the code, can't they just test it themselves?
For a long time, that made sense to me.
Until I started building something of my own.
How It Started
At the end of June, I started building The Last Deploy — an open-source platform where people can learn DevOps and Platform Engineering through hands-on labs.
In the beginning, I made a lot of decisions based on one thing:
If it works, ship it. I'll fix it if something breaks.
I even coded directly on the production server for a while.
Not because it was a good engineering practice, but because it felt faster. There were no users back then, and if I broke something, the consequences didn't feel that serious.
Eventually, I separated development and production environments. That helped, and things worked reasonably well for a while.
But the project kept growing.
And then, people started using it.
The Problem With "I'll Just Test It Manually"
When you're building a small project alone, manually checking whether a feature works can feel sufficient.
You make a change, run the application, try the feature, and if everything looks fine, you move on.
The problem is that your change doesn't exist in isolation.
A change to one part of the codebase can affect something you haven't touched in weeks.
For TLD, that could mean:
- A lab that worked yesterday suddenly fails to start.
- An update to the curriculum breaks existing modules.
- A Docker container fails, but the cleanup process doesn't run correctly.
- The CLI and backend stop handling an error the way they used to.
- Something appears to work locally but fails in another environment.
And you might not notice any of it until someone else runs into the problem.
The more a project grows, the harder it becomes to confidently verify everything manually after every change.
That's where I started reconsidering my approach.
Testing One Feature Isn't the Same as Testing Your Application
Suppose I'm updating TLD's lab execution system.
I test the new feature. It works. Great.
But what about everything around it?
| What I changed | What I still need to verify |
|---|---|
| Lab execution | Do existing labs still run? |
| Docker environment setup | What happens if the container fails to start? |
| Curriculum sync | Are existing modules and labs handled correctly? |
| Error handling | Does the user get a useful error instead of a crash? |
| CLI/backend interaction | Are both sides still communicating correctly? |
Manually checking every possible interaction gets harder as the codebase grows.
And relying on memory to remember everything I need to test isn't exactly a reliable strategy either.
That's the difference between checking whether my latest change works and having a system that helps verify whether the application still works.
So, What Am I Learning About Testing?
I've been learning more about different types of tests and how they fit into a software project.
1. Unit tests
Test a small, isolated piece of logic.
For example, checking whether a function correctly validates lab configuration without needing to start an actual lab.
2. Integration tests
Check whether multiple components work together correctly.
For example, verifying that the backend handles a lab execution request and responds appropriately when something fails.
3. End-to-end (E2E) tests
Test a complete flow from the user's perspective.
For example, checking whether a user can initiate a lab and receive the expected result through the application.
4. Regression tests
Verify that functionality that worked previously still works after a change.
This is particularly important for a project like TLD, where a change to shared execution logic could affect multiple existing labs.
How I think about the difference
- Unit: Does this piece of logic work?
- Integration: Do these components work together?
- E2E: Does the complete user flow work?
- Regression: Did my changes break something that already worked?
Of course, these tests don't guarantee that an application is bug-free. They help catch specific classes of problems before those problems reach users.
And that's already valuable.
What I Want to Do With TLD
I'm not trying to introduce a massive testing framework overnight or chase a particular code coverage percentage.
I want to start with the parts where a regression could have the biggest impact.
My initial focus is on:
- Lab execution and cleanup
- Curriculum synchronization and local file handling
- Error handling and failure scenarios
- CLI and backend interactions
- Existing functionality that could break when shared code changes
The goal is to gradually build a testing suite that gives me more confidence when making changes.
Something that lets me spend less time worrying about what I might have accidentally broken and more time building what comes next.
What Changed My Mind?
I still believe developers should test their own code. That's an important part of writing software.
But I've started to understand why that alone isn't always enough.
When a project is small, you can often keep most of it in your head. As it grows, that becomes increasingly difficult.
And when real people start depending on what you're building, "it worked on my machine" stops being a satisfying answer.
I don't want TLD to be a project where users have to hope that the latest update didn't break something they were using.
I want to build something that I can keep improving without being afraid of every change.
Because, at the end of the day:
Writing code that works is one thing. Being confident that it keeps working as your project evolves is another.
I'm still figuring out the right testing strategy for TLD, and this is just the beginning.
Follow the project: The Last Deploy on GitHub
I'd love to hear from other developers: At what point did testing stop feeling like overhead and start feeling like a necessity?
Top comments (0)