c# - Automated tests on contracts between microservices? -


say have creditcardservice microservice depends on threedsecureservice microservice, communicating using json.

minor changes in api (or implementation) of threedsecureservice silently break creditcardservice (and other potential clients). so, automated tests.

i see 2 flawed approaches, , wondering how improve.

  1. integration testing in threedsecureservice.tests.

the accompanying test project of threedsecureservice have integration test fixed json input. faking out dependencies, run otherwise complete call input, confirming service swallows input.

the problem here if fails realize how changes break clients, 'fix' tests match changes.

  1. integration testing in creditcardservice.tests.

the client 1 wants test assertions threedsecureservice's expected input. however, require client solution include threedsecureservice project, projects depends on. negate many of advantages using microservices!

how make assertions client (safeguarding dependency) without breaking loose coupling using microservices?

i hope i've understood asked, if not following @ least contributes thinking.

the way understand question practical one, i.e. "how organize solutions , projects minimize risk developer breaks service contract without understanding impact have on consumers of service?"

in ideal world, developers don't that. if make breaking changes service, know they've done it, , it's new version. being said, point - it's nice have sort of safeguard against kind of human error since developers perfect of time.

if you're working in environment, you're creating microservices other teams depend on , vice-versa, there's no way around disciplined , structured approach, i.e. proper governance. full test environment mirrors production, services running , can test service integrates services depends on doesn't hurt either.

if you're in control of services need communicate each other, there's (at least in opinion) no reason why shouldn't have single solution service projects included , integration test project starts services needs , checks integrations between them working expected.

your individual microservices shouldn't know outside world, apart contracts/interfaces, , should have unit tests test every microservice in isolation, mocking out dependencies.

if 1 solution becomes large, break smaller pieces, 1 solution each service includes service , nearest neighbours. in example, solution contains threedsecureservice, creditcardservice , creditcardservice.integrationtests (which tests creditcardservice in turn invokes threedsecureservice). way, when developer working on threedsecureservice, integration tests let developer know he/she has broken integration. still requires developer remember run integration tests of course.

the end goal see it, incorporate gate build flow, ensures developers not able publish changes cause integration tests fail, coupled automatic deployment. ensure basic integration errors not make production.


Comments

Popular posts from this blog

Is there a better way to structure post methods in Class Based Views -

performance - Why is XCHG reg, reg a 3 micro-op instruction on modern Intel architectures? -

jquery - Responsive Navbar with Sub Navbar -