hello Meteor friends,
I’m starting to play around with full-app testing lately, but i have a big app with a TON of collections and schemas. writing a separate factory schema for each collection feels like I’m repeating myself when I don’t necessarily have to - not to mention issues arising if the two don’t match, etc.
my initial thought is that you could possibly add a fake() method to collections. i.e use the SimpleSchema as the Factory.define(), and then Collection.fake() to generate the documents. the reasoning would be that your schemas and test collection definitions are coming from the same place?
does this line of reasoning make sense, or would it be redundant to implement something like this?
mike
1 Like
How I wish there was a reply to this.
Your logic seems correct to me, and a reply might have confirmed this.
Take a look at this package:
https://atmospherejs.com/muqube/fake
It let’s you create fake data based off of a schema.
1 Like
mahh man - exactly what I had in mind!!
zero installs though… i would have figured this would be a much more common approach.
It was made by a co-worker and friend of mine for a project. So there are at least a few installs, because we’re using it!
I believe he forked it from the anti:fake package, and then added the schema stuff.
i’ll give it a whirl, looks promising!
Thanks for the tip. Just what I was looking for, and I see it’s easy to add stuff to the fake record created, during the creation.
It also makes mincemeat of nested schemas: it works very well indeed.
Though the question immediately comes to mind is why a simple Date wasn’t included, just wondering.