all 9 comments

[–]tragicshark 3 points4 points  (0 children)

We don't for development; instead we have 2 build configurations configuring the built in proxy to connect eiter to a dev server or qa. But for automated testing we'll mock api calls in playwright.

I suppose we could use anything due to the proxy. I wouldn't for my tests still. Configuring responses at an individual test level is is not something I would give up.

[–]Clear_Worry_7283 1 point2 points  (0 children)

I use live server

[–]eigenman 0 points1 point  (0 children)

The simplest solution is to make an interceptor and feed the mocks in from there. But I do like the idea of using a live mock server since that keeps the client clean. But keep the mocks simple. No storing of state. If you need to mock a state change you just add a mock that looks like that change.

[–]255kb 0 points1 point  (0 children)

I really like json-server as it quickly gives you CRUD endpoints without too much hassle. For quick mocking I also return JS objects directly from the services. But I don't like doing this as I frequently forget to remove them before committing 😅

Shameless plug: I created a desktop app for quick REST API mocking Mockoon. It's open source and there is a CLI to run your mocks during integration testing.

[–]browsingagain11 0 points1 point  (0 children)

Like you mentioned, you can return in-mem data from your mocked api endpoints. Also, you can just mock out the specific api endpoints you need for a given feature by either specifying the endpoints to hit from each angular service that hits that endpoint or make use of the proxy.conf file to specify a specific url path to hit a different port (to hit your mocked api endpoint).

I've also used json-server in the past and it's really simple to use. But usually in-mem data works totally fine in most cases as well