The Setup: A Developer's Hubris
So there I was, Friday night, 11:47 PM. My test suite? Green as grass. Coverage? A beautiful 94.7%. My c...
For further actions, you may consider blocking this person and/or reporting abuse
I've always refused deployments starting Thursday afternoon, because if a serious bug comes up, rolling back to a stable state would require dedicating a part of the weekend to it.
It's better to wait until Monday to start the week calmly and have time to fix things without unnecessary pressure.
This is your first problem. What are you doing so late developing?
That is your second problem. A push to production should be followed by at least a few hours of monitoring.
Going to production at night is a bad idea because the chance people are hitting the changed/new code is going to be smaller. Early releases are better for monitoring.
Sleep is overrated?
While the message in the post is good. The storytelling feels forced. Who is dragging a computer with them on a mountain hike? The main goal of a hike is to get away from the screens you seeing every day.
It looks like a story crafted (or assisted) by A.I
Sharp points, I like it
Yeahh I have exaggerated the storyy may be a little just to make it interesting but yeahh , I work on different shift and trek was unplanned by my friends.
Thanks for the comments though !!!!!
My developer pattern detection alarm went off reading the story. As a hiker and bike traveler myself I detected some things that felt off to me.
Of course if you are still young you are a little more resilient and you are taking more riskily decisions. But that is how you learn.
Actually this a story like from Jan 2025 I wanted to share this , and I was still junior dev and there were rumors of layoffs didn't want to take any risk
Love that you put the TL;DR last. That made me laugh! How many mindless vibe-coders missed that...
But good points about unit testing.
Serious mistake to forget to never put anything into production on a Friday. NEVER!
Great article. I couldn't agree more, especially with your point that integration tests are "not optional."
Your argument that unit tests fail to catch real-world issues like environment drift and integration failures is especially true for microservices. In that world, focusing on implementation-detail unit tests can be actively harmful, as it makes refactoring harder without giving any real confidence.
I recently wrote an article that builds on this idea, discussing how to test a microservice as an isolated component "from the edges" and why contract testing is so crucial. It's a very similar philosophy to what you're advocating for.
You can find it here if you're interested: nejckorasa.github.io/posts/microse...
Cheers!
Greatt!!! Thanks...
I would really love to read the article...
If anyone is still trying to sell the idea that coverage is import, they need to read this paper from the University of Waterloo:
Coverage Is Not Strongly Correlated with Test Suite Effectiveness
cs.ubc.ca/~rtholmes/papers/icse_20...
Testing the fraction of the code that actually matters is way more valuable then testing the rendering behavior of a UX where the spec will change tomorrow.
Exactly!! Sending this to my manager
Was there any mock production server to deploy before the production deployment on Fridays to prevent such cases? Once the team is set for pre prod setup to run smoothly then after a day of test we can go to prod with confidence. Yes, that's it, that's my take on this report.
Whenever I hear from devs about importance of using unit tests, I just nod, knowing that I didn't write them then and won't write them now. Devs write unit tests only after they've f*d up and it's too late. 😅
This is soo true 😂💯. I write test cases bcz my non technical manager is obsessed with coverage
I remember back in my first CS class, the professor emphasized defensive programming. Don't assume perfect inputs, she would say, and she backed it up with chaotic test inputs for all our coding assignments. Years later I get into the industry and suddenly it's code fast/ship fast and unit tests later with weak edge case coverage. But that defensive mindset stuck with me. If I'm reading a table row from the database, I assumed it got deleted before I update it. Every time I hear "that should never happen in production" I assume it will happen. Unit tests won't catch everything but you should have good enough breath and depth coverage to be able to sleep at night.
UPDATE is an atomic operation.
Exactly! That’s why I’m really glad that my product is released only once every few weeks and gets tested by the QA team beforehand. I’m a frontend developer, and I remember having to explain in one of my previous companies why it’s important to have someone in that role - sure, we have unit tests, automation, and all that, but an automated test won’t tell you “something isn’t working in the test environment” or “this feels unintuitive.”
I think deploying more frequently, not less is a better solution.
When it's less frequent the changes are bigger, there's more surface area for problems and the process itself might be more manual and complicated, because it's only done every few weeks.
If you can deploy small changes often you'll have a much smaller window to narrow down targets, and it's a forcing function to incentive good rollback and deployment procedures so the whole thing is less risky and less scary.
You're absolutely right - in general, deploying more frequently is the safer approach. In my case, though, it's not really feasible because the frontend is hosted separately in multiple locations, so coordinating frequent releases becomes very difficult.
Yeahh!!
On Input data: From time to time I unit-test functions that operate on x/y-Coordinates.
I once wrote a test that completed fine. In Prod we found that somehow the x-coordinate is used for all operations, and y is ignored. At some point I accidentally copied x to y.
Ever since, I use different values for x/y for all operations and I use prime-numbers. This way errors accumulate faster.
I'd rather have a dedicated QA teams who wrote testing scenario and bombard the QA environment with their shenanigans (devs can to, if they are trained with tools like Selenium). I'd write unit tests for critical parts of the application (util methods, edge cases), and do some mockings, and a few Integration Test (or how it was named, at least in Java land). But opting for coverage or trying to go above and beyond won't pay off. And it is slow as hell.
Exactlyy!!!!
All of this to explain that Unit Tests cover only the app code, not the environment that run it.
TL DR; - lol, never hotfix / deploy on Friday and you'll be good : )
This sounds a little bit like AI, odd and kinda amateurish. Mixing unit tests with infrastructural problems. This has nothing to do with testing, it’s inconsistency in setup. Unit tests, checks logic.
I agree 😂😅, This is my first time doinga story telling type of blog