The SAAP code pattern can also be quite helpful in providing automating mock and integrated data scenarios. It is hard to give an exact percentage of how much time savings it can provide, but for me it has saved days at a shot.
It is easy to be create multiple variations of the same service in an enclosed space. The root of the service would generally be the core implementation with nested services providing mutations to the original. The general structure and naming convention makes it obvious as to relatedness concise and meaningful names. One major benefit of this structure is to provide a series of static mocked data or freshly generated data is useful for testing and development. Being able to store and retrieve a specific data scenario is specifically useful:
- To reduce or isolating the flow of data for a given process. If there are several steps to access a given set of data, the process can be short-circuited. Setup and navigation time may be substituted with more productive testing and development.
- If multiple people are working against the shared data source, changes to the data may be mistaken as bugs.
- The data exists in a given state for a limited window of time. This is particularly common in any kind of workflow process. If a set of data only naturally occurs at a certain time or times of day. If data needs to be created or improved to be operated in a particular fashion. The data set is resilient by definition and can never be consumed or exhausted.
- A known set of data with a known expected outcome may be more effective in validating the specific behavior of the app for a given set of circumstances.
- Certain aspects of UI testing may be more safely and reliably conducted with less dependency on the database.
- Freshly generated data can help to accelerate the various stages of integration.
To implement, simply provide a series of nested services. For instance, if you have a service with the name of Buy, you could add a series of nested classes scenarios of: Five Items, Ten Items, as well as No Items. A tilde delimited string could provide a simple routing mechanism. The tilde may look something like this:
Additional corresponding services could be added coinciding with the same scenarios. For instance, a Sell service could be created, implemented some of the Buy scenarios.
- Buy~Ten –> Sell~Ten
- Buy~Five –> Sell~Five
If a given scenario is not represented, it may fall back to the previous generation.
- Buy~None –> Sell
This form of routing could be packaged in as part of the primary URL route, the query string or a form variable. Of course, it should be clearly visible in the display when test data is being used as to not inadvertently mistaking it for real data.
Here is a link to example source code.
In the source code, the files: MyService.cs, MyService~Mock.cs, and MyService~Mock~Error.cs each represent the various layers where data could be either mocked or constructed (through integration). The corresponding Context class is the class that actually gets constructed.
The HelperService.cs provides a means to dynamically construct Services. It can be altered and configured based on the individual project needs.
The Test project demonstrates how the corresponding Context is constructed and call.