I am in the process of setting up ember tests for the first time and one big question is how to deal with data mocking.
I was wondering if anyone had any insight as to pros and cons for Mirage and Factory Guy
I know mirage is based on mocking an entire server which seems good in the sense that it matches reality a little bit more closely but it also seems like extra work both in writing the mocks and instantiating them.
I was wondering if anyone had any perspective on that trade off or any other anecdotal experience about which they had liked more and why.
In my opinion, the difference of features is blurring between the two, but the API and history makes it all. Here’s a list of comparison points that I can think of:
Mirage always focused on mocking the server, which makes it agnostic to Ember adapters. Mirage goes with or without Ember Data.
FactoryGuy focuses on Ember Data. If you don’t use EmberData, move away from FactoryGuy.
Â
FactoryGuy seems to have a nicer/more complete API for handling HTTP errors in tests. Or at the very least, closer to the standard API we’re used in testing our Ember apps.
But I didn’t notice any difference in the feature set on mocking HTTP behaviour.
Â
Mirage started with Fixtures and added functionnality up to factories along the way.
FactoryGuy started with factories in mind, they’re more powerful, with traits and globally better specifications of “what I want to test now”. “Simple” fixtures are possible but it’s ridiculous tu use FG with static fixtures (which is both a pro and a con).
Â
FactoryGuy allows for a greater variability of your tests, but comes at a cost.
Mirage is simpler, but edge cases will stay hidden from testing until you manually add them.
Â
tl;dr; Mirage is easier and faster, but FactoryGuy more powerful and heavyweight.
my personal preference:
I personnally went with Mirage and apart from the management of relationships (which is getting better and better), I never had to complain.
FactoryGuy is a very muscular beast, but I’m afraid at some point you’re in need to test the factories you use for testing, if you see what I mean.
Excellent and very in depth comparison! I think I was conceiving of what their strong points were incorrectly in some cases so this was very clarifying.