41–50 of 52 posts
I believe Michael Feathers was just started a Twitter thread yesterday that talked, among other things, about moving IO to the edges of your code. If you can divide acquisition from usage, I wonder how much less effort you need to put into API mocking. Ages ago and shortly after I started testing, was the last time I had to do any low-level HTTP response processing. My coworkers could not fathom why I had divided the…
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).
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)
Much appreciated Sam and much love ️
I believe Michael Feathers was just started a Twitter thread yesterday that talked, among other things, about moving IO to the edges of your code. If you can divide acquisition from usage, I wonder how much less effort you need to put into API mocking. Ages ago and shortly after I started testing, was the last time I had to do any low-level HTTP response processing. My coworkers could not fathom why I had divided the…
But being able to go down to the HTTP level and mock responses there provides a different benefit. You are able to do end to end tests but isolated to your own service. I always do that (alongside unit tests) so I can even catch errors outside of my code base, i.e. in my dependencies.
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).
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.
I have been using https://github.com/nock/nock in Node.js for ages and I love it as well.
Hello! I'm Sam and I built Mirage JS to be a framework-agnostic API mocking library. Mirage is extracted it from an addon that's been widely used in the Ember ecosystem for the past 4 years, at companies like Apple, Heroku, Square and Footlocker. Nearly all frontends need to talk to an API, no matter what framework they're built with! So over the past year I've made Mirage work with any tool or test runner. I really…
Phenomenal landing page. The first text I read is a ~10-word description of the value proposition. The next thing my eyes are drawn to is a visual demo. The first thing I can click is a link to use it myself. Plus, it's all visually very appealing without being distracting. Well done.
Is it possible to include it as a standalone js file? Instead of using npm or yarn?
I'm a bit of a noob so hang with me here. So you install it as a dev dependency via npm. So is it running ... with the client app as a proxy between the client application and just waiting for the API requests and taking those responding? Is it possible to configure some delay in responses?
You can also configure a universal delay if you’re using mirage in development and want to get a feel for your app with a certain amount of latency.