-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Unit tests should avoid expect().not.toBeNull() and .not.toBe(null) #5479
Comments
|
(1 failure) |
This seems backwards... In JavaScript, it("shouldn't get confused about null and undefined", function () {
var obj = {};
expect(obj.bar).toBeUndefined();
expect(obj.bar).not.toBeNull();
expect(obj.bar).not.toBe(null);
expect(obj.bar).toEqual(null);
}); It seems that it's actually the |
Ahh, I see what you're getting at. The |
#5492 appears to have taken care of this. FBNC to @peterflynn |
Whoops, looks like a new reference to this snuck into @jasonsanjose Is there any way we could make a Travis test that verifies the strings ".not.toBeNull()" ".not.toBe(null)" and don't appear anywhere in the files being submitted? Otherwise this might be a never-ending whack-a-mole. Unless there's a way to patch the Jasmine APIs to disallow those constructs... |
We could write a crude grep grunt task to do this. It wouldn't necessarily be Travis specific, but we could run during the travis build and have it pass/fail the build. |
Issue #5479 - Change .not.toBe(null) to .toBeTruthy in DocumentManager-test.js
Closing since all the usages of this are gone for now |
These forms will pass when
foo === undefined
, which is almost always not what was intended (masking real failures):We should replace them with one of these safer forms:
Personally I prefer toBeTruthy(), but we could pick either one to standardize on.
We have 60+ instances of the unsafe form in our codebase right now, including unit tests in extensions/default.
The text was updated successfully, but these errors were encountered: