Moving on from mocks that perhaps return optional content from a fixed set of static responses or use simple scripts to generate responses, there are database-driven mocks that are capable of storing and retrieving data from requests or preloaded test data.

One of the core concerns when deciding on how best to mock a service is minimizing the cost of its implementation, as the mock normally needs to be available quickly, and its implementation will often be considered a throwaway. This recipe shows a low-cost way to enable a SoapUI mock to use a light in-memory database to preload, store, and retrieve the request data.