In any production distributed system, testing is crucial: services don't make it into the production environment unless they've passed rigorous tests in unit, system, and user-acceptance environments. Running services in non-production environments is typically easy if you have all the deployment artifacts close to hand, and a bed of appropriate sample data to fuel testing - generally, in any solid development environment, this is going to be the case.
Many services, however, do not live in isolation: the implementation of their business logic may require other services further down-stream. So, in order to test your service, you've got to deploy the down-stream services as well. Sometimes, however, you don't have access to the back-end service deployment artifacts, so you can't deploy an instance of this service in your test environment.
I worked recently with a customer who had exactly this problem: their system depended on a third-party service for which no test environment was readily available. As a result, they could not test their own service in a timely fashion; instead, they had to negotiate a "testing window" with the third-party, and run all their tests within this testing window. The delays in making these test windows available were seriously impacting this customers ability to roll-out new releases of their product, holding up their design, test and development process.
So - how does Artix solve this problem? Using Artix it's possible to rapidly build and deploy a service simulator (or "stub") that can be deployed in a test environment, allowing you to continue with the testing of your core systems. Using Artix allows you to pursue a number of different "Service Simulation" strategies:
- Randomized Service Simulator.Using Artix's code generation tooling, a service implementation can be generated, compiled and deployed in minutes that generates randomized responses to incoming requests. This is a great way to ensure that connectivity between your software and the stub is being exercised, and can assist in performance and stability testing. One draw back of this approach is that, if your own system performs data validation, then the random values returned may be inappropriate.
- Black-box Service Simulator.Using the Artix "Universal Test Harness" framework, you can define a set of pre-canned responses, providing rules on when each response should be used. For example, if a
valdateCreditCardNo()operation arrives with a well-known test string such as"1234-1234-1234-1234", then return a response that indicates a successful validation.Black-box stubs can be built in a matter of hours, and are suitable for stateless services where all the information required to return a valid response is present in the incoming message. The approach is called "black-box" because it treates the service as a black box and does not attempt to simulate internal business logic of the service.
- White-box Service Simulator. There are times when black-box approaches (outlined above) are not rich enough to simulate the required behaviour. For example, consider an interaction where a test client invokes
getCustomerDetails(String id),updateCustomerDetails(String id, Details d)and thengetCustomerDetails(String id). A typical client-side test would expect that the second call togetCustomerDetails()would return a different response from the original call, where the customer's details have been updated accordingly.
Recall that the black-box approach is good for simulation of stateless services; here, the service is stateful: it must rememember the customer's details across different invocations. This use-case requires white-box simulation, where code is implementated that simulates some of the service's internal business logic. Artix provide a set of productivity tools, through its tight integration with Eclipse, that allow such services to be rapidly constructed within a day or two.
The simulation approach you should use is goind to depend on the semantics of the service, and the kind behaviour you want to simulate.