Why Tobiloba Aramide Ogundiyan Believes Testing Isn’t Optional

In the high-stakes world of backend engineering, Tobiloba Aramide Ogundiyan stands out not just for his skill with distributed systems and email authentication tools in Go, but for his unwavering stance on one fundamental principle: testing isn’t optional.

To Tobiloba Aramide Ogundiyan, testing is more than just a technical best practice, it’s a philosophy, a mindset, and a safeguard against failure. As a lead backend engineer at Apprentice Systems, where he oversees the development of open-source components for email validation and system alerts, he’s learned firsthand how untested code, however elegant, can become a liability. His blog, Aramide.dev, is filled with real-world stories of debugging chaos, lessons from production outages, and hard-won insights on building reliable systems. And one theme runs through all of it: if you're not testing your code, you're gambling with trust.

From Theory to Production

Most engineers acknowledge the value of testing in theory, but in practice, many still treat it as a nice-to-have. Tight deadlines, feature pressure, or even overconfidence in one's logic often result in shipping code without sufficient coverage. That approach is simply not acceptable for those who prioritize long-term stability over short-term speed.

"Tests are more than just finding bugs," he says.“They are about making sure the promises your software makes, whether to a user, a client, or another system, are real, measurable, and repeatable.”

Projects involving sensitive systems, including email authentication standards (SPF, DKIM, and DMARC), require accuracy.A subtle bug or misconfiguration could result in rejected legitimate emails—or worse, letting malicious ones slip through undetected.

“Testing gives us confidence,” he says, “not just that the code works now,but that it will keep working even after refactors, even when the load triples, even when unexpected edge cases show up in production.”

Testing as Communication

Tests are also a form of communication. “Well-written tests act like documentation that never goes stale,” he writes on his blog. “They describe how the system should behave in specific scenarios, often more precisely than comments or README files ever could.”

In complex systems like distributed alerting pipelines, unit tests define contracts between components. Integration tests ensure those contracts hold under pressure. And end-to-end tests simulate real-world use cases to validate the entire user experience. By testing deeply and intentionally, teams ensure that future maintainers can clearly understand what the system expects and tolerates.

This level of clarity pays off significantly during debugging. "When a test fails, it's not a disaster—it's a clue." It tells you exactly where to look and what just broke.”

Go and the Test-First Mindset

Working primarily in Go, a language that champions simplicity and explicitness, he finds the built-in testing tools to be one of its biggest strengths.

“Go makes testing frictionless,” he says. “There’s no excuse not to write tests. The tooling is fast, the syntax is clean, and the language encourages modular, testable design.”

A typical workflow doesn’t begin with implementation, but with writing the test case first. This test-first mindset helps focus on defining behavior rather than obsessing over implementation. Whether validating email headers, tracing log flows, or benchmarking concurrent workloads, writing tests first makes the design clearer and the goals measurable.

This approach also accelerates iteration. “If I know my tests are solid, I can move fast. I can change the internal design with confidence, because the tests will catch any regressions,” he explains.

Resilience Through Tests

A deep commitment to testing directly shapes how resilience is viewed, not just as maintaining uptime, but ensuring predictable behavior under stress.

“Reliable systems are systems you can trust to behave the same way tomorrow as they did today,” he says. "Proving your system’s reliability through frequent testing is how trust is built."

Every distributed system faces inevitable disruptions,sluggish responses, broken services, or corrupted data packets. Resilient systems are created by anticipating these events rather than hoping they won't occur.By replicating failure conditions,like connection drops, unexpected inputs, or hardware faults,during testing, engineers can design systems that recover smoothly.

"A system that hasn’t been tested against failure is more likely to break unexpectedly in production."

Beyond the Codebase

What truly sets this engineering approach apart is not just the practice of testing,but the act of documenting and sharing the learning process behind it. On his blog, readers will find more than just test cases and benchmarks. There are stories: honest reflections about mistakes, edge cases that were missed, or unexpected behaviors that only surfaced when the right test was finally written.

He claims that he writes tests for the team rather than simply the code.“For the next developer who picks this up. For the operator who receives a page at two in the morning. For the customer who just wants things to work.”

It’s this human-centered approach that elevates testing from a mechanical duty to an act of care.

Conclusion: Making Testing Non-Negotiable

Setting discipline and predictability as a top priority has a subtly potent effect in a tech sector that frequently encourages haste and heroic cures.For engineers who value reliability, testing isn’t a final step,it’s the foundation of trust.

While tools, frameworks, and paradigms may evolve, one principle remains evergreen: If it matters, test it.

Or, as he puts it best: “Tested code tells the truth. Untested code only tells a story you want to believe.”