This week I hit a really satisfying milestone on my current project, PingVertex (a full-stack uptime monitoring platform). My test suite just crossed 991 passing tests!
I've been focusing heavily on making the background workers as robust as possible. A huge chunk of these tests are verifying edge cases like:
Graceful Shutdowns: Ensuring that async workers and proxy checkers properly halt on server cancellation.
Idempotency & Reconciliation: Strict checks for the auto-top-up billing logic to handle amount/currency mismatches and provider failures without ever double-charging.
Concurrency: Testing the tenant suspension schedulers that run in the background.
The backend is built with Axum, Tokio, and SQLx (PostgreSQL), and I'm using Leptos for the frontend. Seeing all these tests pass concurrently is a great reminder of why I love building with Rust—refactoring complex async logic feels so much safer.
The amount of tests is a useless metric. What is your goal here? Getting a thousand tests? Getting as many tests as possible?
You should think about why you're testing what.
If you want code coverage, its percentage may or may not be a useful metric to judge your tests by.
But a raw number of tests tells you nothing about the overall code quality.
PS
After sleeping about it, I realize that my above answer may have a bit... direct.
Given possible cultural differences, I wanted to clarify that it was not my intention to step on somebody's toes, though I could have phrased my response a bit more considerately.
I understand your point from a purely metrics perspective, but context matters. For me, this is absolutely a milestone worth celebrating.
As a solo developer, I have spent the last 8 months tirelessly architecting this system and solving these specific edge cases (idempotency, concurrency, and graceful shutdowns). The goal wasn't just to write a thousand tests, but to achieve a deeply reliable architecture.
Seeing the entire suite pass after 8 months of hard work means I have finally achieved the exact system stability I was aiming for. The number itself might just be a number, but the completion of that 8-month journey is a huge personal win.
for every decision in your code have you checked that it works in all cases?
For example if you have something like:
if x > 10 {
// Something
}
Have you checked that "Something" happens when x has the edge case value 11. And does not happen when x has the edge case value 10?
This might sound silly but a test with x as some low value and x as some high value will get you 100% code coverage but does mean anything as it does not not actually check the threshold is correct.
This might sound silly but these details were an essential part of my testing aircraft control systems back in the day. Every decision point had to be tested around that point. Which gets complicated when there are multiple conditions combined with AND and OR operations etc.
I did not mean to suggest you were failing for not being as stringent as those testing flight controls. Almost nobody does that. Certainly not me most of the time. We have to estimate the likely hood of failure and the importantly impact of any failures and adapt our degree of rigour accordingly.
It's just that you are, rightly, pleased at getting lots of tests passing and I want to remind not to become complacent as result.
Your situation resonated with me because I have been working on something somewhat security critical recently. So I have a lot of tests for it. But being security problem there is the constant doubt about having left some hole open. Have I tested everything, are those tests sufficient, what have missed, it's a bottomless pit.
That makes complete sense! It's very true that testing can feel like a bottomless pit, especially when security or high availability is on the line. The paranoia of "what did I miss?" is definitely real!
I appreciate the reminder to stay grounded. Wishing you the best of luck with your security project—sounds like a tough but rewarding challenge!
Haha, that's a fair question! 991 wasn't a pre-planned target number.
It just happens to be the exact number of tests currently in the suite at the moment I finally got all the complex background worker logic to pass concurrently.
The "milestone" wasn't the number 991 itself, but rather achieving the system stability and getting a completely green test suite after months of architecting those workers. I'm sure I'll hit 1000 very soon as I add more features!
