-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple test from the default resolver for initializers_test #15367
Conversation
d8efa0f
to
37b82c3
Compare
try { | ||
app.boot().then( | ||
(app) => { | ||
assert.ok(false, 'The boot promise should not resolve when there is a boot error'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that, we are pausing & resuming the test runner here. But why? Would like to know the reason behind this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
app.boot().then(() => {
is not inside a runloop, so the thennable callback will be called in an autorun making it async. I think you could avoid the async-ness if you wrapped the promise a runloop, it would then flush in the actions queue. Nice catch:
try {
this.runTask(() => {
app.boot().then(app => {
assert.ok(false, 'The boot promise should not resolve when there is a boot error');
}, error => {
assert.ok(error instanceof Error, 'The boot promise should reject with an error');
assert.equal(error.message, 'boot failure');
});
});
} catch (error) {
// ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many of the changed I'd like to see are already laid out in #15362, but I'll reiterate a few:
assert
is passed as the first argument to tests, should be used for assertions instead of the globals.this.runTask
is preferred overrun
run
shouldn't be needed aroundinitializer
calls
Excellent beginning though, thank you for the continued iteration!!
super(); | ||
} | ||
|
||
createApplication(options, MyApplication) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using applicationOptions
is preferred here. Replace createApplication
through teardown
with:
get applicationOptions() {
return assign(super.applicationOptions, {
rootElement: '#one'
});
}
createSecondApplication(options, MyApplication=Application) {
let myOptions = assign(this.applicationOptions, {
rootElement: '#two'
}, options);
let secondApp = this.secondApp = MyApplication.create(myOptions);
return secondApp;
}
teardown() {
super.teardown();
if (this.secondApp) {
this.runTask(() => this.secondApp.destroy());
}
}
More details at https://github.com/emberjs/ember.js/pull/15362/files#r122541946
cc26055
to
2d0bd15
Compare
2d0bd15
to
4221a0d
Compare
This PR is ready to go. // @mixonic |
This looks great to me, thanks @Karthiick 👍 I kicked the sauce build, it had what I presume was a spurious failure. |
#15058