Contract-Driven Testing in Banking: Realistic Mocks - Phil Royston

Ten systems stuck in acceptance testing, and how contract testing frees the tester Contract-driven testing lets a tester work against a realistic mock instead of waiting for 50 integrated systems to behave, and that is what Phil Royston is bringing into a large bank. We talk about why mocks built on a developer's imagination produce unreliable tests, how agreed contract tests turn into mocks for API consumer and provider, and why the pitch to senior management fits on one slide while the middle managers hold the veto. Phil also explains why approved business requirements were not testable ones, what he means by parasitic end-to-end testing, and why his advice to any test manager is to wait for the crisis. "They're not realistic, because they're not real. They're just imagination." - Phil Royston Phil Royston started out on a journeyman IT career in the late 1980s and fell into the software testing world in 2002, where he has stayed ever since. He has worked as a developer, team leader, tester, test manager and consultant, and eventually co-founded Tesena | Smart Testing with the slightly ambitious, but very seriously intended, goal of changing the software testing world. He has a soft spot for personal and professional challenges and is drawn towards IT projects where good people have ambitious goals to deliver great business value. He enjoys helping them solve their testing and quality challenges by bringing a more human and pragmatic perspective. Over the years he has learned that teams rarely need miracles. They need clarity, context, trust, consistency and a few sensible ideas. Highlights: Contract-driven testing turns the agreement between API consumer and provider into tests the provider must pass in CI before anything reaches the integration environment. Mocks built from a developer's imagination of an interface are not realistic, which is why 100 percent code coverage can sit next to terrible code. The same contract tests generate a mock, so consumers and testers work in their development environment instead of waiting for 50 integrated applications. Phil Royston sold contract testing to senior management with one promise, shorter testing in the release cycle, while middle managers holding the budgets took longer to win over. Approved business requirements turned out not to be testable; it took testers asking why and a painful round with the analysts before the bank had requirements worth testing. 🚀 Do you like the podcast? Then please rate and share it. And feel free to send feedback to podcast@testing-unleashed.fm