An App Without Testing: Everything That Can Go Wrong

There is one eternal dialogue that plays out in every other software company in the world. The project manager says: "We don't have time for tests, we need to ship on Friday." And the developer replies: "Okay, but..." — and that "but" hangs in the air like a harbinger of disaster.

Over fifteen years, we have seen things. Things that will make you believe automated tests are the single best investment you can ever make. Let me walk you through stories of apps that went into the world without proper testing.

The E-Commerce Store That Gave Away Weekend Discounts for Free

One of our clients came to us with an online store built by another team. Everything worked perfectly — from Monday to Friday. On weekends, though, strange things started happening: customers were paying significantly less than they should have.

The cause? Time zones. The discount system worked with UTC time, but the "is the promotion active?" check used the server's local time. Every Friday at 11 PM, the weekend discount activated — a full hour early. And on Sunday at 11 PM, it deactivated — an hour too soon.

This is not an exotic edge case. This is a classic. But nobody tested it with different time zones, nobody wrote a test that verified the transition across midnight. The result? Three months of incorrect prices and losses in the tens of thousands of dollars before anyone noticed.

Lesson learned: Time is a treacherous enemy in programming. Always test edge cases around midnight, daylight saving transitions, and different time zones.

The Social Network That Shared More Than It Should

This is a story that still gives us chills. A small social application, something like an internal company chat. The private messaging feature worked beautifully — until the server started having performance issues.

A developer added a caching layer. Messages were stored in cache using a key that, unfortunately, was not unique enough. When two users sent a message in the same second, the cache keys collided. The result? User A could see User B's private message.

Nobody caught this during development because manual testing involved one person sending messages at a time. It was only when 200 people started using the app simultaneously that panicked reports started coming in: "Why can I see Peter's conversation with HR about his resignation?"

A load test would have caught this in five minutes. But load tests were skipped because "it's just an internal tool for 50 people." It ended up being 500.

Lesson learned: User privacy is not something you can test "when there's time." Cache invalidation is one of the hardest problems in computer science — and it deserves its own test suite.

The Banking App That Stole Pennies

A story straight out of the movie Office Space. A banking application rounded transactions. The problem? It always rounded down. Each transaction lost a fraction of a cent, and those fractions went... nowhere. They simply vanished.

On a single transaction, it was $0.002. Nothing. On a million transactions per day, it was $2,000. Per month, $60,000. Per year, nearly three quarters of a million dollars. Money that simply evaporated in a rounding error.

The fix was trivial — proper banker's rounding (half-even rounding). One line of code. But nobody wrote a test that summed up a thousand transactions and verified that the total balance was accurate to the cent.

Lesson learned: In financial applications, test arithmetic obsessively. Small errors at scale become catastrophes. And never use floating point for money.

The Form That Accepted Absolutely Anything

"Validation? We'll get to that in phase two." Famous last words.

A registration form for one application accepted anything containing an @ symbol as a valid email. So asdf@ was valid. @@@ was valid. Even an empty string with a single @ sign passed validation.

But that was not the worst part. The form also did not sanitize special characters in usernames. So someone registered as <script>alert('hacked')</script> and every visitor to their profile saw a JavaScript alert. A classic XSS attack, in the year 2024.

And the cherry on top? The phone number field accepted letters, so the database contained entries like "dunno", "will call later", and one creative user entered an entire sentence.

Lesson learned: Input validation is not a "nice to have." It is the first line of defense for your application. Every form field is a potential entry point for an attacker — or a creative user.

Why Don't People Test?

We hear the same excuses over and over:

• "We don't have time for it." — But you have time to fix production bugs?
• "It's a simple application." — A simple application with simple bugs that cost real money.
• "We'll test it manually." — Manual testing covers the happy path. Automated tests cover a thousand edge cases.
• "Tests slow down development." — No. Bugs in production slow down development. Tests speed it up in the long run.

What You Should Test at a Minimum

You do not need 100% code coverage. But certain things should always be tested:

1. All financial calculations — every computation involving money must have tests.
2. Authentication and authorization — who sees what, who can do what.
3. Input validation — what happens when a user enters something unexpected.
4. Time-related edge cases — midnight, leap years, daylight saving changes, time zones.
5. Load scenarios — what happens when you get 100x more users than expected.

Testing Is Not a Luxury, It Is Insurance

Every story above had one thing in common: the fix cost many times more than prevention would have. The e-commerce store lost tens of thousands. The social network lost user trust. The bank faced an audit.

Testing is like car insurance. You pay for it and hope you never need it. But when you drive into a tree, you are incredibly glad you have it.

Next time someone says "we don't have time for tests," remember that e-commerce store with the weekend pricing bug. And then make the time.