-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[CHORE tests] modernize unit/model/lifecycle-callbacks-test #5717
Conversation
65634f7
to
4801ee4
Compare
assert.strictEqual( | ||
lifecycleEventMethodCalls, | ||
1, | ||
'We do not trigger didDelete when we first call record.deleteRecord' |
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.
We do trigger didDelete
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.
Fixed
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.
thanks!
return person.save().catch(reason => { | ||
assert.ok(reason.isAdapterError, 'reason should have been an adapter error'); | ||
await person.save().catch(reason => { | ||
assert.strictEqual(lifecycleEventMethodCalls, 1, 'We trigger becameInvalid when we reject'); |
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.
Just curious, what are the reasons for preferring strictEqual
over equal
in some cases?
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 use strictEqual
when we do expect strict referential equality. The advantage is two-fold: (1) it avoids a set of bugs that happen when qunit attempts to do deep recursive "looks like the same thing" comparisons when strict equality is not matched (on records this is a mega perf hit in addition to being risky), and (2) it is an improvement over the alternative pattern of assert.ok(foo === bar, '')
wherein if the assertion fails there is no additional information printed about what the incorrect value is without stepping into the test.
ported from #5708