Clean Code (Unit test)
Salut ! Aujourd’hui, j’écris sur Clean Code d’Uncle Bob.
Here’s your sentence corrected to be clear and natural, while keeping your casual tone:
Hey folks today I wanna write about a new chapter of Clean Code. In this chapter, we’ll talk about unit tests so here we go!
P.S: I’m currently learning French at the A1 level, so I try to write some French texts with you guys because I want to improve. Right now, I’m still a n00b, so yeah :)))
Alright, so I know most programmers hate writing tests. Some of them think it’s just a waste of time but hear me out.
After re-reading Chapter 9 of Clean Code by Uncle Bob, I realized something: you’ve gotta see your app’s domain on a deeper level. When you’re working on a large-scale SaaS project, you can’t just write code and hope it sticks. You’ve gotta care about everything especially tests.
A codebase without tests is actually worse than a codebase with a bunch of messy tests. Why? Because even when your tests are dirty, at least they represent your understanding of the domain and subdomains of your project. You might have a bunch of “crappy” tests LOL, but at least you know what’s going on under the hood. That’s the worst-case scenario. The real nightmare is when you work on an enterprise project with no tests at all so please, dawg… write your tests.
Clean Tests Matter Too
Now that we know why we should write tests, let’s talk about why they need to be clean.
If your test code is messy, it’ll eventually wreck your whole project. Dirty tests grow alongside your production code, and over time, they’ll turn your beautiful architecture into spaghetti :/// . You’ll spend more time fixing your tests than actually building features.
Your test files should be small, readable, and repeatable. Seriously readability is everything. You’re not the only one working on this project, and future developers (or even future you) will thank you for making your tests easy to read and understand.
Get Elliot.’s stories in your inbox
Join Medium for free to get updates from this writer.
Think of your tests like art every function you test is a brushstroke on your project’s canvas. You want it to look like a masterpiece, not a crime scene. So take the time, make them clean, and make them meaningful.
The Payoff
Your code’s reliability, maintainability, flexibility, and performance all depend on how well you write your tests.
- When you test your functionality thoroughly, you deepen your understanding of the product’s domain that’s maintainability.
- When your tests are clean and modular, they show your code’s flexibility you can move things around without breaking everything.
- And when you can run those cute, tiny tests in any environment, that’s reliability.
Running all your tests together also helps you catch performance bottlenecks early. It’s like doing a full-system check before a flight you make sure everything’s smooth before takeoff.
Uncle Bob’s F.I.R.S.T Principles
Now let’s get into the good stuff the legendary F.I.R.S.T. principles from Uncle Bob. If you follow these, your life (and every other dev’s life) will be so much easier.
F->Fast
Tests should run fast. Like, blink-and-they’re-done fast. If your tests take forever, no one’s gonna run them and that defeats the whole purpose. Keep them lean and snappy so you can run them constantly without slowing down your flow.
I ->Independent
Each test should stand on its own. No test should depend on another test to run first. If one fails, it shouldn’t drag others down with it. Think of them as solo artists, not a boy band everyone should be able to perform alone.
R -> Repeatable
A test that sometimes passes and sometimes fails? That’s not a test — that’s chaos. Your tests should be repeatable on any machine, any environment, any time. Determinism is key here.
S -> Self-Validating
Tests should tell you clearly whether they passed or failed. No guessing, no manual checking, no reading logs for an hour. You hit “run,” and boom green means good, red means fix it.
T -> Timely
Write your tests at the right time. That means writing them before or during implementation not after you’ve already built the whole thing. The later you write your tests, the harder it becomes to test properly.
At the end of the day, following F.I.R.S.T. makes your codebase more maintainable, reliable, and flexible. It’s not just about catching bugs it’s about building confidence in your code. Because when your tests are clean, fast, and fun to run, you stop dreading them and start loving them.
So yeah write your tests, keep them clean, and make me proud LOL
Btw tnx for reading this story, Have great day, Cheers Elliot.
