Using Mock Services to Develop and Test

Here are some of the reasons why you might consider creating mock services:

  1. Create your TypeScript interfaces and data models early in the development process
  2. Develop the UI/UX before your web services are available
  3. Test the flow of your application without using real web service calls
  4. Unit Testing

I. Create your TypeScript interfaces and data models early

A common place to start an application is by understanding and modeling the data. The mock and actual class will use the same TypeScript model.

Here is a very simple data model:

example model

Here is a simple TypeScript interface for a data service.

example interface

To reiterate, both the mock and actual services will use the same TypeScript interface. When creating the class that consumes the service, simply import the model and interface.

import model and interface

II. Develop the UI/UX before the your web services are available

Another advantage of mock services is that you can start development earlier. In an ideal world, the web services you require will be ready when you begin your project — but often they are not. Fortunately, this does not mean you have to delay development. You can create mock services to simulate web service calls.

The following is an example of a mock service. It uses the model and interface shown above. The example is written in Angular, but the principals are the same for all client-side libraries and frameworks (Angular, React, Vue, Knockout, etc.)

import { Injectable } from '@angular/core';
import { IItemsService } from "./../../services/interfaces/items.service";
import { ItemModel } from "./../../models";

@Injectable()
export class MockItemsService implements IItemsService {
  private readonly MOCK_DELAY: number = 1000;

  constructor() {
  }

  public async getItems(listName: string): Promise<ItemModel[]> {
    return new Promise<ItemModel[]>((resolve, reject) => {
      const items: ItemModel[] = [
        { Id: 1, Title: "Mauris consectetur dapibus lectus non posuere" },
        { Id: 2, Title: "Sed lacinia ligula ut consectetur varius" },
        { Id: 3, Title: "Quisque elementum orci sed feugiat tristique" }
      ];

      setTimeout( () => {
        resolve(items);
      }, this.MOCK_DELAY);
    });
  }
}

III. Test the flow of your application without using real web service calls

When you are ready to test your application, you can do so by using the “gulp serve” command in your terminal.

gulp serve

Your application is now in debug mode, and it does not have any context (no SharePoint context, etc.) The only way to get data is by using your mock services. But how do you tell your project which service to use – mock or production?

The following code is taken from a real project for a policy manual, so the code is different from the examples above. First, we import the ConfigurationService and then the test/prod versions of each service:

import services

Here is the basic structure:

Test (Mock) Production
MockPolicyItemsService PolicyItemsService
MockSearchService SearchService

In Angular, you define the “providers()”, which is an array of class references for NgModule declarations. The “if” condition is how your code will know which services to use (mock or production).

  protected get providers(): any[] {
    if (Environment.type === EnvironmentType.Local) {
      return [
        { provide: PolicyItemsService, useClass: MockPolicyItemsService },
        { provide: SearchService, useClass: MockSearchService }
      ]
   }
 else if (Environment.type === EnvironmentType.SharePoint || Environment.type === EnvironmentType.ClassicSharePoint) {
      return [
        { provide: PolicyItemsService, useClass: PolicyItemsService },
        { provide: SearchService, useClass: SearchService },
      ]
   }

If you are using React instead of Angular, one option is to check the EnvironmentType and set the service references in the onInit() method:

protected onInit()  {
    if (Environment.type === EnvironmentType.Local) {
        this._policyItemsService = new MockPolicyItemsService();
        this._searchService = new MockSearchService();
    } else if (Environment.type === EnvironmentType.SharePoint || Environment.type === EnvironmentType.ClassicSharePoint) {
        this._policyItemsService = new PolicyItemsService();
        this._searchService = new SearchService();
        this._policyItemsService.webPartContext = this.context;
    }

That’s it. You are now ready to test your code without connecting to real web services!

Unit Testing

Another advantage is that your application is better prepared for unit testing, a topic I will cover in a future post.

How Can We Help? Find out how Lone Peak Software can help with Office 365, SharePoint and Azure.

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close