Distributed processes are a fundamental part of your business. Therefore, you must ensure that they behave correctly before you bring them into production. In addition, you must have mechanisms in place to track problems and fix bugs in the event that problems arise.
Services are a natural fit for unit testing. For each individual service, it should be relatively easy to implement unit tests. Because services should be self-contained, unit tests that test the interfaces will usually also be self-contained. The only problem is providing test data so that the service running in test mode can be semantically validated.
For a basic service, you need some way to provide test data for the backend only, which should be relatively easy (you may already have such data available). However, as you'll see in the next section, for more complicated services testing can be more difficult.
Note that if you generate service code, test code may also be generated. This minimizes the effort required to write unit tests (see Generated Service Code).
Testing composed or process services can become a real problem. Because these services use multiple backends, you need consistent test data distributed over all the backends. In systems with different owners and interests, this can become a nightmare. If this is not possible, you will have to simulate other services that are used (which lowers the quality of the test).
One option that I've seen is to replace ...