Contract testing is an increasingly popular approach to make sure different services work well together and don’t break agreed upon contracts between services. The team I joined last year was using Spring Cloud Contract Testing as a tool for this.But with 206 contracts for only 15 other services, the contracts weren’t used for their intended goal of making sure the mocks we test against are valid responses of other services; they were used to test different scenarios inside our own service. To make things worse, the other services were not even using the contacts to make sure they didn’t break their API; we had no guarantee these contracts were valid! The time waiting for these tests to run became a pain point. The “contracts” were just expensive mocks; time consuming to initialize, run and maintain.In this talk, I will tell you how we replaced unreliable and time-consuming tests with faster tests and faster mocks, while increasing test coverage and decreasing our build time. You will learn how to look at your testing needs and your architecture, designing automated tests as feedback mechanisms that provide the right information at the right time, by using the right place for each test rather than adding tests into default boxes. This might help you think about your test strategy, and what to test where and how.