hwillson / meteor-stub-collections

Stub out Meteor collections with in-memory local collections.
MIT License
24 stars 17 forks source link

stub-collections seems a little slow #20

Closed charlesdeb closed 6 years ago

charlesdeb commented 6 years ago

I am using practicalmeteor:mocha to run my unit tests. It reported to me that some tests were taking over 100ms to run - because I am using the dburles/factory package to put some stuff in my database and then test a collection helper (dburles/meteor-collection-helpers).

I thought that using your package might speed things up a lot. But it actually really slows it down. I am using the collections2 package - and that may be relevant.

Anyway, my non-stubbed code is:

it("returns first and last name when both supplied", function() {
  const user = Factory.create("user", {
    firstName: "Charlie",
    lastName: "Brown"
  });
  expect(user.displayName()).to.eql("Charlie Brown");
});

This usually takes between 100-120ms to run. The stubbed code is:

it("(STUBBED) returns first and last name when both supplied", function() {
  StubCollections.stub([Meteor.users]);
  const user = Factory.create("user", {
    firstName: "Charlie",
    lastName: "Brown"
  });
 expect(user.displayName()).to.eql("Charlie Brown");
 StubCollections.restore();
});

and usually takes a little over 300ms to run. Is this expected behaviour? I am running these tests on the server, so maybe that is defeating the whole purpose of this package?

charlesdeb commented 6 years ago

OK, I think I have figured this out for myself... I think I can bypass collections in a Mongo database (whether on disk on a server or in memory on the client's browser) and just do something like this:

 let user = Factory.build("user", {
    firstName: "Charlie",
    lastName: "Brown"
  });
user.displayName = Meteor.users._helpers.prototype.displayName;
expect(user.displayName()).to.eql("Charlie Brown");

which now runs in about 20ms. Sorry for bugging you! I am marking this closed.