The Bug That Passed Every Test and Still Lost Me Money

I am building an automated stock trading bot in public. I am not a developer by trade, so I lean hard on tests to feel safe shipping. Which is exactly why this one stung: a bug that passed every single test I had, and still lost me money the moment it touched the real market.

The suite was green, so I trusted it

Every test passed. I deployed. That green checkmark felt like permission.

The problem was hiding in plain sight: my tests fed the bot clean, well behaved data that I made up myself. The code did exactly what I told it to do. My tests just never told it to handle the real world.

What actually happened

The bot runs a routine at the end of the trading day. My tests used fixed timestamps, so timing itself was never really under test.

Live, the server ran on UTC while the market runs on Eastern time. The end of day routine fired before the session's data was actually final, so the bot made decisions on half baked numbers.

# what I had (naive)
now = datetime.now()          # server's timezone, not the market's
if now.hour >= 16:            # "after close"... in the wrong timezone
    run_end_of_day()

It looked correct. It passed. It was wrong about the one thing that mattered: which clock the market actually runs on.

Why the tests missed it

Unit tests prove your code does what you told it to do. They do not prove your assumptions about the outside world are right.

I had tested the logic and skipped the environment. Market hours, timezones, holidays, missing data, none of it was in my tests, because I was hand feeding the inputs. A green suite told me my code was consistent. It said nothing about whether it was correct.

What I changed

Tests now use messy, realistic data: wrong timezones, missing bars, holidays, odd prices.
Anything time related is explicit and timezone aware. No more datetime.now() and a hopeful guess.
New rule: nothing goes live until it has survived small, real stakes, not just the test suite.

The takeaway

A green test suite means your code is consistent, not that it is correct. For anything that touches the real world, and money most of all, test the world, not just the function.

I am documenting this whole build in public, including the tools I recommend to run it and the bruises like this one. If you want to follow along, everything lives at Bot and Bull.

This is education, not financial advice.