search

m-a-r-c-e-l-i-n-o / jspm-mock

The "jspm-mock" module swaps any type of jspm module with an alternative. Essential for mocking dependencies in unit tests.
Other
0 stars 1 forks source link

What is jspmMock.get for? #1

Open joeldenning opened 8 years ago

joeldenning commented 8 years ago

Why would I want to use jspmMock.get(...).then(...) instead of just System.import(...).then(...)? Also, why does jspm-mock assume that I want the default exported value, without the named exports?

m-a-r-c-e-l-i-n-o commented 8 years ago

Thanks for looking at this!

Why would I want to use jspmMock.get(...).then(...) instead of just System.import(...).then(...)?

Mainly because of these lines. Imagine that module "x" is imported with no mocked dependencies, then you decide to mock "y", which is a dependency of "x". If you did System.import(...).then(...) instead of jspmMock.get(...).then(...), you would keep importing "x" with its old "y" dependency. Crucial? Maybe not (since the user is unlikely to use it that way). I just found it to be simpler to ensure correct behavior this way. Does that make sense?

Also, why does jspm-mock assume that I want the default exported value, without the named exports?

Yeah, maybe it shouldn't. What do you think should happen in this case, just serve as is?

joeldenning commented 8 years ago

If you did System.import(...).then(...) instead of jspmMock.get(...).then(...), you would keep importing "x" with its old "y" dependency

That makes sense -- it's sort of an interesting concept. Wouldn't it be problematic though for people who are using the import keyword (instead of System.import) because they need modules to be mocked but cannot easily switch from import jquery from 'jquery' to jspmMock.get('jquery').then(..) because of synchrony vs asynchrony?

What do you think should happen in this case, just serve as is?

Yes I think so -- the default export will be available as myModule.default, which is something that the systemjs community is already very familiar with since it is how System.import works.

m-a-r-c-e-l-i-n-o commented 8 years ago

Wouldn't it be problematic though for people who are using the import keyword (instead of System.import) because they need modules to be mocked but cannot easily switch from import jquery from 'jquery' to jspmMock.get('jquery').then(..) because of synchrony vs asynchrony?

That's part of the problem, atm, when using "jspm-mock", (unlike node's commonjs) you can't just mock then import because of the async nature. The first thing I thought of was to try to work with the import keyword. After a few hours of getting no where, I moved on this other approach. I can't imagine it being that difficult to transition into jspmMock.get('jquery').then(..) from import jquery from 'jquery' simply because you would only need to change your main files (which are most likely your specs). Besides, even if you solved this issue, you would still have to deal with the stale variable issue. Not saying it's not possible, but far from trivial to do it without having the user changing the way they do things. I'm open to ideas, if you have any.

Yes I think so -- the default export will be available as myModule.default, which is something that the systemjs community is already very familiar with since it is how System.import works.

Okay, I'll update it. I really wasn't too sure of this one when I did that, it just seemed more convenient.