tags:

views:

29

answers:

3
A: 

First of all, in case you're thinking of automatically doing an "Update Service Reference" in your CI build for every service reference, think again. You don't want to do that - you want to think about it ahead of time, do the updates for each referencing project, build them locally, run their tests, etc. You don't want the build doing that for you just because there's been a change in the contract - the clients might not yet be read for such a change.

Second, I think the only useful definition of "breaking change" in this context is to run all your automated tests, and see if any break. That's what CI tests are for in the context of other code; why make it different for services?

John Saunders
A: 

As mentioned a few times already this is more of an integration test, and is probably significantly too much work to actually do. But you could use a discovery mechanism to find the available contract and generate characterization tests around them. Each time you deploy the service you rerun the checks to find all places where changes have occurred.

This is only a rough idea of course. It should be possible, but that said let me really strongly suggest that this be well down your list of priorities. Writing effective unit tests and good development practices should minimize the potential problem here, and is a lot simpler of a nut to crack.

Matt
+1  A: 

If you break your contracts out into a separate assembly and then reference it from both the client and the server then any breaking changes will show up immediately upon compilation. Sharing references like this has been covered many times here on SO, so i won't go over it again.

Where you will run in to trouble is if you are relying solely on a generated proxy on the client side, as the other posters have already answered you will not be able to test this unless you deploy and run integration tests post build. If this is your situation then you need to refer back to my first paragraph and reference the same interfaces from the different assemblies.

slugster