[shhsshs]

What is the benefit of a request mocking framework versus hiding all api requests behind a module?

Instead of

    // MyComponent.js
    const users = await fetch(...

Use this

    // MyComponent.js
    const users = await api.getUsers()

    // api.js
    export default {
      getUsers() {
        return fetch(...
      }
    }

To mock, you replace the entire api module (or individual functions).

[mupkoo]

Mirage is not just a request mocking framework. It comes with an ORM and a way to define factories, so you can create random data with ease, while you are testing your app.

I am sure that you can do all without Mirage and I am sure that your solution might fit your project best, but I doubt that it will take you the same amount of effort

(I have been using Mirage for the past 4 years and I love it)

[cbhl]

The first page of the docs list a few reasons.

https://miragejs.com/docs/getting-started/introduction

"Use a client-side interceptor to handle your app's network requests. ... This is the most flexible approach, but it requires you to start from scratch in each project, and leaves it up to you to enforce conventions across your apps."

"Importantly, because Mirage mocks the HTTP boundary instead of the JavaScript code your app uses to make network requests, you never need to modify your application code to account for whether your app is talking to Mirage or to your real production backend."

[rclayton]

How is this the best/most flexible approach? What if you decide to move from REST to GQL? GQL to websockets? By mocking the HTTP endpoint you’re too low in the stack. At that point, I feel like you might have better success with using the actual backend and swap out the DB with mock data.

[KitDuncan]

I always use this approach for my E2E tests. This way I test the backend as well as the frontend. Harder to setup properly though.

[kostarelo]

The benefit is doing integration tests, testing the glue between your components. By mocking down to the HTTP level you can be sure that the code will work end to end, which is inside your whole codebase.

Imagine that fetch suddenly has a bug (extreme example but it could be another open-source library). Your tests above wouldn't catch it.

I always strive to do at least a few integration tests like these and not stand purely on individual unit tests.

[rclayton]

100% agree. I feel like you could do the same with a mocking library and good abstractions. At the end of the day, you still have to simulate the backend API. I would love to see front end developers adopt Domain Driven Design.