| I wrote a blog post a couple of weeks ago that may answer some of your questions: https://www.specto.io/blog/recipe-for-designing-building-tes... In answer to your specific questions #1 If you are testing system-level (end-to-end) functionality the separate repo definitely. If you are testing service (component) level functionality then store tests in the same repo as the service and virtualise/mock dependent services #2 Opinions in the industry are split here - Adrian Cockcroft often suggests using client libraries (as do the Datawire.io team), but I don't always because of the developer maintenance cost of these libraries (and forget it if you are using multiple/polygloy languages in your stack). If I understand your question correctly I think you would benefit from reading about Consumer-driven Contracts, as this will help you detect contract/API breaking changes #3 You can either entrust your build pipeline to manage this (I've used the Jenkins promotion plugin to do this kind of thing), or you can use yaml config files to specify service runtime dependency requirements (kind of like Maven or Ruby Gems etc, but at runtime), or if using REST/HTTP you can deploy two service versions at any given time and user the 'Accept' request-header to specify which versions of services can communicate with each other Feel free to DM me if you have any further questions! |