moduleFor* integration: true

[stefanpenner]

moduleFor("model:user", {
  integration: true // <-- unsure what this key should be named
});

what does this do?

if true, it disables isolated container.
if false (the default) maintain the current isolated container.

[dgeb]

@stefanpenner is the idea here to create an integration test that automatically starts the app and evaluates the subject in the context of the app's container?

This will also have an effect on the setup of the test context: https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/test-module.js#L89-L108

[stefanpenner]

@stefanpenner is the idea here to create an integration test that automatically starts the app and evaluates the subject in the context of the app's container?

no, the idea is to merely disable the isolated container.

Some future work can be done to go beyond this. Unfortunately people abuse initializers, so we can't really trust them to purely add injection rules :(

[dgeb]

no, the idea is to merely disable the isolated container.

Ok, so these tests will be "bring your own container" and not provide a container, factory or default subject to contexts?

The factory used to create the subject is currently looked up from the container: https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/test-module.js#L98

[stefanpenner]

Ok, so these tests will be "bring your own container" and not provide a container, factory or default subject to contexts?

These tests will have a container that has access to the apps resolver, so it can auto-resolve things that exist rather then relying on 'needs'.

This still leaves us without container rules provided during initialization, these rules I honestly believe we need to decouple from initializers and instead make them more first class entities. Like assemblies. This theoretical entity could be used without having to boot the whole app. I think we are close on this front, but still more work togo.

[dgeb]

I think I understand your intention and the integration flag now makes sense.

So we'll need an application in order for initializers to be invoked (unless your refactoring idea changes this), but these tests will stop short of fully booting the app.

[stefanpenner]

Ya. Maybe it will prove valuable to actually boot the app but let's try first without

[jvenezia]

Hey, is there a workaround here ? (related to https://github.com/rwjblue/ember-qunit/issues/70)

I'm trying to test a controller action which needs a store.

Thanks

[johnnyshields]

Ping on this issue. Quite an annoyance to include N models into each test file, and it becomes an excuse ultimately not to test!