We recently re-factored some of our code into smaller Micro-services, and a need for acceptance/integration has become more urgent. The plan is to use RSpec to write those tests, but I'm not sure where those acceptance/integration tests should be sitting in git-wise. Those are the two option:
Keeping them where the code of the Microservice sits - this keeps coupling between testing and develop code - so we can easily revert into previous state where tests were running if we want. However, some service are written in Java/Scala - so bundling Ruby code in the same repository feels wrong. Also, some Integration code does not specifically targets a single micro-service - it's just the entry point where the whole flow starts. Keeping testing code that not directly touches the micro-service or setuping an environment that applies to other Micro-service on an entry-point microservice just because it's the first microservice in line feels smelly.
Separate Integration tests and develop code (so each will have his own repository). This feels more 'single responsibility' in design, not to mention it can help keep some code DRY (as multiple Micro-service entry point might be using the same code and this saves us the need to extract this code out into a Gem or something). But the obvious problem is losing the coupling between the test/dev code. I need to keep a version tagging on the micro-service, and manually picking the right tag from the integration tests repo that works against it.
I'm wondering how you guys do that.