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 parsing and networking code into completely separate sections. Then I showed them how stupid-simple most of the tests were, instead of the convoluted mess of integration tests I'd walked into.
Hand the payload to I/O-free code immediately. You've done the hardest part at this point. Mocking out the network layer in any of half a dozen ways is a cakewalk in comparison.
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(...
// MyComponent.js
const users = await api.getUsers()
// api.js
export default {
getUsers() {
return fetch(...
}
}
Just my two cents: Mirage is freaking great because it makes mocking shit out pretty much as easy as possible and pretty damn correct.
I don't know how many times mocking up a UI I start to throw some random JS objects in a file and then inevitably after a few hours, those random JS objects are unmanageable and contain very small differences between what my API will deliver.
Using Mirage from the start of projects has made my life a lot easier, it also provides a nice sanity check between what the backend delivers and what the frontend actually expects.
Mirage is a staple of Ember development. It's one of those things I didn't realize I was missing until I learned it, and now I can't imagine not using it(at least in early development). I kinda didn't realize I could use it outside of Ember CLI, so this is pretty cool.
I've used mirage extensively throughout the past 5+ years across multiple projects/teams and it truly is a great tool. In a recent project we had multiple "scenarios" defined that represented different high-level states of the app. We added a page that allowed switching between the scenarios during local development and it was a huge boon to productivity, while also allowing us to write certain automated smoke tests that otherwise would have been more cumbersome with e.g. selenium.
Working on a React project recently, I was surprised that there wasn't an option like mirage, but now that there is, I highly recommend it!
I would rather make a component that takes data as props.
Now make a component on top that runs a network request and injects the network response into it.
Now you have a reusable component independent of the api. Your network function can be tested individually. Your top level component doesn’t need testing as that is the part that would be mocked.
You can now test your actual component without any mocking.
If you need some dummy data to show before the backend team is ready, this is trivial. Guess I’m just not a Big enough mocking fan to ever need a library for what is such a small thing in my experience
I used Mirage with Ember for many years and it has changed the way I think and approach front-end acceptance testing. I was very excited to see the work to extract the Ember-specific bits from the rest of the library (originally by @cowboyd / Charles Lowell and now from the original author Sam Selikoff himself) and am using it with a React app to great success.
You beat me to this idea but I'm glad you did. Nice library. Mock API's are quite the productivity multiplier. I use them extensively for local development, prototyping, testing, and demoing. I've hacked similar things for work; first one was based on jsondb and the second one was based on axios-mock-adapter.
Colorizing[1] the console logs for quickly parsing success and failure might be a nice addition. [1]: https://developers.google.com/web/tools/chrome-devtools/cons...
edit: grammar
Been using the original Mirage project on an Ember app for years (testing and fake offline demos functionality), and now this iteration takes it over the top. I can't recommend it enough.
I remember using Mirage back when I was an Ember developer. Everything else seemed so backwards in comparison, and honestly still does. I'm definitely interested in trying this out.
This is cool. Mockability is one reason I've been so heavily biased to choosing GraphQL for my backend APIs recently. GraphQL makes it super easy to (a) first define a contract between client and server, and then (b) front end teams can trivially mock this out to develop the front end while the backend team actually implements the API.
Glad to see something like mirage solving this across all different types of API frameworks.
This is awesome! Exactly the kind of library I’ve been looking for.
Does anyone have any suggestions on a way to start with an OpenAPI spec and end up with a mock data set? With Mirage it seems easy enough to mock our API directly from scratch, but if we could save a few steps and go from OpenAPI spec to mocked front end that would be bliss.
I've used Mirage for a bit while working on an Ember project. It was really awesome and user-friendly and easy to use.
I have been using https://github.com/nock/nock in Node.js for ages and I love it as well.
At our job we used to mock both frontend and backend and we needed consistency, so to help us I developed https://mockadillo.com which is imho easier to use than embedding mocks in your code.
Great tool! I cannot say how much I like using Mirage, and how much it helps me while developing applications. I have used it only with Ember.JS and I always missed having it while using some others JS frameworks.
Much appreciated Sam and much love ️
We use Mirage for a large scale ordering front-end built with Ember. It’s enabled almost zero flakiness when writing our acceptance tests; super excited to see the library get ported outside the Ember ecosystem!
Thank you! I hacked something similar quick and dirty, but i will use definitely Mirage with my next project.
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?
Nice tool. But apart from the great landing page, what's the difference with FakeRest [0]?
This looks really cool. Is there a difference between this and json-server [0]?
Is it possible to include it as a standalone js file? Instead of using npm or yarn?
Finally a library to help me make a mockery of my project!
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 believe deeply in the frontend-first workflow, and Mirage makes that easier than ever. If it sounds interesting to you, check out the lib + let me know what you think!