How to use with integration tests?

[ZackMattor]

https://github.com/danielspaniel/ember-data-factory-guy/blob/v2.1.3/tests/components/dude-translator-test.js

You shouldn't use startApp in integration tests... Is there no way to do it without doing so? If i don't use startApp it can't seem to find the factories.

[danielspaniel]

Hmm .. interesting .. why not use startApp for integration test?
And startApp well, it starts up an application, which runs the initializers, which set the store in factory guy and then tells factory guy to find the factories and load definitions. I would personally love to get away with not having to use starApp ( startup an application ) to achieve this .. so I am open to new ideas.
If you look at the initializer at:
https://github.com/danielspaniel/ember-data-factory-guy/blob/master/app/initializers/ember-data-factory-guy.js
you'll see what is happening

[ZackMattor]

Yeah.. I see why you need to do it now.. I originally posted this because i was having a problem with startApp throwing exceptions regarding using the same rootelement for multiple instances of the app.. which I think i resolved (now working the way you suggested), but a bunch of people in the EmberJS Community slack, including @rwjblue, said it's a "bad" to use startApp in integration tests.

[danielspaniel]

I think your on to something though, because there might be a way to not have to do that ( startApp ) .. though it depends on how your writing the integration tests. If your using the new moduleForAcceptance thing a bob for integration tests, then you don't have to startApp, since that is doing it for you. So, to say using startApp is "bad" is going agains what they are doing.
So maybe you can clarify ( ask them ) what they mean?
Because I am sure they mean something, I am just not sure exactly what it is.

[rwjblue]

moduleForAcceptance is for acceptance tests, not integration tests. Acceptance tests boot a full app which means initializers run. Integration tests are attempting to be more isolated than is possible with a full application, and do not boot a full application (which means initializers are not run).

My suggestion would be to provide a helpful function that folks can import and invoke in their integration test's beforeEach to ensure that this lib is properly initialized without having to rely on initializers there.

[rwjblue]

Also, I very specifically quoted "bad" because as with everything: it isn't that simple 😈

[danielspaniel]

Good point about acceptance vs integration tests.

Good suggestion .. about providing a function .. I will ponder that one ( though it might not be so easy since I have to get access to store, and container .. )

I was hoping to think of some other way to do have FactoryGuy automatically initialize somehow but I have not been able to think of one.

I am wondering if I should make FactoryGuy into a service so I can setup a directive to have it initialize with container setup .. so it's then available and ready to go as a singleton. Does this seem like a good approach? Would that work for the integration tests or other tests like moduleForComponent that setup limited containers?

[danielspaniel]

As of version 2.1.4 ( just published ) .. you can now use a method called
manualSetup, passing it this current container .. see this file:
Sample component test #2 (dude-translator-manual-setup-test.js):
for example usage in an integration test

I will close this issue. But feel free to open it again if you need to throw popcorn and beer bottles at me ( to show how unsatisfied you are )

[ZackMattor]

👍 we are currently using manualSetup and it's working great. Thanks for that!

[danielspaniel]

Me loving that feature too. Thanks for suggestion, and let the good suggestion ( times ) roll!