Skip to content
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

assert: introduce deepStrictEqual #639

Closed
wants to merge 1 commit into from

Conversation

vkurchatkin
Copy link
Contributor

deepStrictEqual works the same way as strictEqual, but uses === to compare primitives and requires prototypes of equal objects to be the same object.

Fixes: nodejs/node-v0.x-archive#7161

R=@iojs/collaborators

@vkurchatkin vkurchatkin changed the title assert: introduce deepStictEqual assert: introduce deepStrictEqual Jan 28, 2015
@Fishrock123
Copy link
Contributor

There was a large discussion in IRC a couple weeks ago on why this didn't make semantic sense.

Basically strict and deep are mutually exclusive; having them both together means having a deepStrictlyQucksLike() with duck-typing for only some things.

While such a structure can still be useful, I'm not sure if it is actually good.

See @othiym23's deeper and deepest.

@mscdex
Copy link
Contributor

mscdex commented Jan 28, 2015

What about primitives? Think about if you're trying to do a assert.deepEqual() on two objects, where one object has foo: 5.2 and the other has foo: '5.2'. assert.deepEqual() would consider those two objects equal, whereas a assert.deepStrictEqual() would not.

@vkurchatkin
Copy link
Contributor Author

Basically strict and deep are mutually exclusive

Why? I don't get it.

@Fishrock123 Fishrock123 added the semver-minor PRs that contain new features and should be released in the next minor version. label Jan 28, 2015
@Fishrock123
Copy link
Contributor

See the conversation following: http://logs.libuv.org/io.js/2014-12-15#19:43:36.553

I'll re-read the conversation again tonight as I would like this kind of feature.

@vkurchatkin vkurchatkin added the assert Issues and PRs related to the assert subsystem. label Jan 28, 2015
@vkurchatkin
Copy link
Contributor Author

what I want is feedback from people. I personally expect asserts to be as strict as possible in tests

// if one is a primitive, the other must be same
if (util.isPrimitive(a) || util.isPrimitive(b))
return a === b;
if (strict && Object.getPrototypeOf(a) !== Object.getPrototypeOf(b))
return false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still going to suffer from the things discussed in #621

Are we sure this shouldn't just check primitives? Otherwise we might as well just do a regular strictEquals().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what you mean. recursively call deepStrictEqual on prototypes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at the tests and it seems as I would expect. I think I mis-understood points made in the previous thread.

@Fishrock123
Copy link
Contributor

LGTM

@vkurchatkin
Copy link
Contributor Author

Ok, so the PR has been approved by TC. I'm not sure it's ok to merge it now since we don't have a branch for next minor release and I don't know if want to do 1.2.0 right after 1.1.0 /cc @chrisdickinson

@vkurchatkin
Copy link
Contributor Author

rebased the PR. can anyone take a final look? @bnoordhuis maybe

toString: function() { return this.first + ' ' + this.last; }
};

function nameBuilder(first, last) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't constructor name start with an uppercase letter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be honest, I just copied all the test for deepEqual and changed doesNotThrow to throws and vice versa where appropriate. This test doesn't make much sense, but I decided not to remove anything.

@tellnes
Copy link
Contributor

tellnes commented Feb 6, 2015

Except for the naming thing in the test, it LGTM.

@vkurchatkin
Copy link
Contributor Author

tweaked tests to make a bit more sense and removed copy-paste artifacts

@@ -23,11 +23,12 @@ Tests shallow, coercive non-equality with the not equal comparison operator ( `!

## assert.deepEqual(actual, expected[, message])

Tests for deep equality.
Tests for deep equality. Primitive values are compared with the equal comparison operator ( `==` ).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make lines wrap at 80 columns?

assert.throws(makeBlock(a.deepStrictEqual, new String('a'), ['a']), a.AssertionError);
assert.throws(makeBlock(a.deepStrictEqual, new String('a'), {0: 'a'}), a.AssertionError);
assert.throws(makeBlock(a.deepStrictEqual, new Number(1), {}), a.AssertionError);
assert.throws(makeBlock(a.deepStrictEqual, new Boolean(true), {}), a.AssertionError);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you fix the long lines in this file?

`deepStrictEqual` works the same way as `strictEqual`, but
uses `===` to compare primitives and requires prototypes of
equal objects to be the same object.

Fixes: nodejs/node-v0.x-archive#7161
@vkurchatkin
Copy link
Contributor Author

@bnoordhuis Wrapped some lines, reworked weird test to just compare arrays and added some tests for primitives. PTAL

@bnoordhuis
Copy link
Member

@rvagg
Copy link
Member

rvagg commented Feb 9, 2015

just land it @vkurchatkin, it'll hit 1.2.0 and I think we have reached a point of acceptance on this (re TC meeting specifically).

lgtm from me

vkurchatkin added a commit that referenced this pull request Feb 9, 2015
`deepStrictEqual` works the same way as `strictEqual`, but
uses `===` to compare primitives and requires prototypes of
equal objects to be the same object.

Fixes: nodejs/node-v0.x-archive#7161
Fixes: #620
PR-URL: #639
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-by: Rod Vagg <[email protected]>
@vkurchatkin
Copy link
Contributor Author

landed in 3f473ef

@vkurchatkin vkurchatkin closed this Feb 9, 2015
@Fishrock123 Fishrock123 added this to the 1.2.0 milestone Feb 9, 2015
rvagg added a commit that referenced this pull request Feb 11, 2015
Notable changes:

* stream:
  - Simpler stream construction, see
    nodejs/readable-stream#102 for details.
    This extends the streams base objects to make their constructors
    accept default implementation methods, reducing the boilerplate
    required to implement custom streams. An updated version of
    readable-stream will eventually be released to match this change
    in core. (@sonewman)
* dns:
  - `lookup()` now supports an `'all'` boolean option, default to
    `false` but when turned on will cause the method to return an
    array of *all* resolved names for an address, see,
    #744 (@silverwind)
* assert:
  - Remove `prototype` property comparison in `deepEqual()`,
    considered a bugfix, see #636
    (@vkurchatkin)
  - Introduce a `deepStrictEqual()` method to mirror `deepEqual()`
    but performs strict equality checks on primitives, see
    #639 (@vkurchatkin)
* **tracing**:
  - Add LTTng (Linux Trace Toolkit Next Generation) when compiled
    with the  `--with-lttng` option. Trace points match those
    available for DTrace and ETW.
    #702 (@thekemkid)
* npm upgrade to 2.5.1
* **libuv** upgrade to 1.4.0
* Add new collaborators:
  - Aleksey Smolenchuk (@lxe)
  - Shigeki Ohtsu (@shigeki)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assert Issues and PRs related to the assert subsystem. semver-minor PRs that contain new features and should be released in the next minor version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants