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.
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.
That is incredibly insightful, and coming from someone who tested aircraft control systems, I can completely understand why you view testing through such a rigorous lens!
You make a great point about boundary testing versus just hitting code coverage. I've definitely focused heavily on state transitions and edge cases (like handling concurrency, database transaction failures, and idempotency), but I'm sure there are thresholds in the code that could use tighter boundary testing exactly as you described.
Since PingVertex is a web-based uptime monitor and not a life-critical system like an aircraft, my definition of "system stability" here is more about fault-tolerance, graceful degradation, and safely recovering from unexpected states rather than mathematically proving every single logical gate.
But I genuinely appreciate you sharing this perspective—it's a fantastic reminder not to get completely blinded by high test counts and to always question the boundaries of our logic. Thank you!
