You know that feeling when something technically works… but it just feels off? That’s where we were with our API testing setup. We were using Tosca to test our backend, which is built on Azure Durable Functions. It was technically doing the job—but it was slow. Really slow…. A full test cycle could take up to two days. And any time something failed, we were deep in post-deployment logs trying to figure out what went wrong. It wasn’t sustainable. Not for the team. Not for delivery. And definitely not for the pace we were trying to move at. So, we took a step back and asked: Can we do this smarter?
What We Changed
We made a decision to shift our API testing left—closer to development, where it belongs.
That meant:
- Moving away from Tosca for most of our API-level tests and also for this project in durable functions
- Writing tests in NUnit in this case, as it is a .Net project, right alongside our code
- Using Rest Assured .NET to keep the tests readable and expressive
- Mocking external services with WireMock.NET, so we didn’t need to spin up real dependencies
- Running everything locally with Azurite, which mimics Azure Storage (important for our Durable Functions)
We didn’t just change tools—we changed the way we thought about testing.
What It Got Us
Honestly, the results surprised even us.
What used to take up to two full days and the first results show us that it runs in 7.5 minutes in our pipeline for 100+ plus tests
We’re still running deployment tests as a final safety net, but the heavy lifting happens way earlier now—before code even gets close to production.
And along the way, we picked up a few other wins:
- Developers can run the full suite on their machine before they even commit
- We cut down on licensing costs
- And best of all, our feedback loop went from “see you tomorrow” to “you’ll know in a few minutes”
It Wasn’t Just a Tech Shift—It is a Culture Shift
The biggest difference we will expect? Dev and testers started caring more about the tests.
Because the tests are fast, relevant, and easy to run, developers actually used them. QA wasn’t stuck maintaining a giant suite on their own. Everyone had more confidence in what we were shipping, because we could catch issues so much earlier.
We are aiming to move testing at the end to testing while building. And that changed everything.
Final Thought
If your team is still doing heavy, post-deployment API testing and it’s starting to feel like a drag—this kind of shift might be worth considering. Now, testing fits into the way we work—not the other way around. if you need any support we are gladly to help. We didn’t just speed up our test pipeline—we gave our team back time, focus, and confidence. And sometimes, that’s the best kind of progress.