sapui5tutors SAPUI5 • Fiori • SAP BTP Step-by-step tutorials Real project examples Interview Q&A
Practical SAPUI5 • Fiori • SAP BTP tutorials and interview prep

SAPUI5 Mock Server: Frontend Development Without Backend

Don't Wait for the Backend

Frontend work stalls when the OData service isn't ready — or when it's down, slow, or missing the entity set you need this sprint. sap.ui.core.util.MockServer removes that dependency: it intercepts your app's OData calls and answers them with local data.

Your app code doesn't change at all. Bindings, filters, and batch requests all work against the mock exactly as they would against the real service.


Setting It Up in Five Minutes

The MockServer reads your service's $metadata and generates plausible data for each entity set automatically. Drop a mockserver.js into your app's test folder:

sap.ui.define([
  "sap/ui/core/util/MockServer"
], function (MockServer) {
  "use strict";
  return {
    init: function () {
      var oMockServer = new MockServer({
        rootUri: "/sap/opu/odata/sap/ZPRODUCT_SRV/"
      });
      // path to local metadata + auto-generated mock data
      oMockServer.simulate("../localService/metadata.xml", {
        sMockdataBaseUrl: "../localService/mockdata",
        bGenerateMissingMockData: true
      });
      oMockServer.start();
    }
  };
});

With bGenerateMissingMockData: true, you don't even need to hand-craft JSON files — the server invents rows from the metadata. Override the generated files only where realistic values matter for your UI, like product names or status codes.

Point your app at the mock by loading mockserver.js before the component starts in your test harness page. Production code never knows the difference.


Simulating Real-World Behavior

A mock that always answers instantly teaches you nothing about loading states. The MockServer lets you tune the simulation:

  • Response delay: oMockServer.setRequests(...) or the global delay config simulates network latency so you can verify busy indicators.
  • Error simulation: intercept specific requests and return 400/500 responses to test your error dialogs and message handling.
  • Custom logic: oMockServer.attachAfter("POST", fn) lets you mutate mock data on create/update, so a full create-read-update flow works end to end.
// simulate a failed create to test error handling
oMockServer.attachAfter("POST", function (oEvent) {
  var oXhr = oEvent.getParameter("oXhr");
  if (oXhr.url.includes("Products")) {
    oEvent.getParameter("oFilteredData"); // inspect payload
  }
});

Say you have a form with draft validation: simulate the 400 the real backend would return, and you can build and test the whole error UX before the backend team finishes the service.


Keeping Mocks Honest

Mocks drift. The metadata evolves, someone adds a required property, and your UI works against the mock but breaks in QA. Two habits prevent this:

  • Regenerate or refresh mock data from the real $metadata whenever the service changes.
  • Run the same app against the real backend in a nightly or weekly check — even a smoke test through the main list catches schema drift fast.

The mock is a development accelerator, not a contract. Treat metadata refresh as part of your sprint routine.


Final Take

MockServer turns backend downtime into frontend velocity: simulate metadata-driven data, add delays and errors to harden your UX, and keep the mock in sync with the real service. Your sprints stop waiting on the backend team's timeline.

Do you generate mock data or hand-craft it? Share your approach in the comments.