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: combine user and generated message #22695

Closed

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Sep 4, 2018

There are lots of PRs that remove the message property assert calls. That message is actually pretty valuable and should not be removed. However, the message alone is often not that useful. In context with the auto-generated message it can be very valuable.
From now on it would also be possible to provide the actual input value to functions and similar instead of having to reconstruct what value the assertion failed upon:

assert.strictEqual(foobar(input), 'output', input)
assert.ok(/regexp/.test(input), input)

Before, all values were coerced to a string and passing through a message would have resulted in [object Object] as output. Now the value is inspected and fully visible.

There is only one values that is not accepted as input: instances of Error (those are special handled in the way that that concrete error would be thrown in case of an failed assertion. Therefore even if someone does not anticipates this case, it's always a good assertion output). I have a follow-up PR to add support for undefined as well.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label Sep 4, 2018
@BridgeAR BridgeAR added the semver-major PRs that contain breaking changes and should be released in the next major version. label Sep 4, 2018
@Trott
Copy link
Member

Trott commented Sep 5, 2018

Seems like the documentation changes could benefit from a bit of editing. @nodejs/documentation

@Trott
Copy link
Member

Trott commented Sep 5, 2018

What about instances where expected and actual are very long values and the use of the message to suppress them may therefore be desirable?


Type: Runtime

Instead of accessing the generatedMessage property of `AssertionErrors`, please
Copy link
Contributor

Choose a reason for hiding this comment

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

generatedMessage -> `generatedMessage`

Type: Runtime

Instead of accessing the generatedMessage property of `AssertionErrors`, please
check for `AssertionError#userMessage` existence instead. It contains the actual
Copy link
Contributor

Choose a reason for hiding this comment

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

Is double "Instead of... instead." OK in this sentence?

* `operator` {string} Set to the passed in operator value.
* `userMessage` {any} Contains the actual passed through message by the user.
It will not be set in case the user does not provide a error message.
Copy link
Contributor

Choose a reason for hiding this comment

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

a error -> an error

@vsemozhetbyt vsemozhetbyt added the deprecations Issues and PRs related to deprecations. label Sep 5, 2018
@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 5, 2018

@Trott

What about instances where expected and actual are very long values and the use of the message to suppress them may therefore be desirable?

The actual and expected values will be cut off by default if they are very long. Especially, if there are only few differences in the diff (collapsing of matching parts). Therefore I do not worry about the extra lines.

@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 5, 2018

CITGM https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1533/

fastify has test failures due to sniffing the message. I'll open a PR to fix those. The rest seems green.

@@ -74,6 +93,7 @@ try {
assert.strictEqual(err.code, 'ERR_ASSERTION');
assert.strictEqual(err.operator, 'strictEqual');
assert.strictEqual(err.generatedMessage, true);
assert.strictEuqal('userMessage' in err, false);
Copy link
Member

Choose a reason for hiding this comment

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

typo: strictEqual

@BridgeAR BridgeAR requested a review from a team September 5, 2018 19:20
@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 5, 2018

PTAL

This PR makes all the "remove third argument in assert calls" obsolete.

Refs: #22718

@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 6, 2018

I opened a PR to fix the fastify issues. Refs: fastify/fastify#1142

@fhinkel fhinkel removed the request for review from a team September 6, 2018 04:33
@Trott
Copy link
Member

Trott commented Sep 6, 2018

Might be worth pinging some mocha people (@boneskull) and code/lab people (@cjihrig, @geek) to see if this is likely to have any impact on users of their libraries. (I'm guessing not, but let's be cautious anyway.)

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

I don’t understand why this PR would cause such a breakage. That seems a very common pattern, and not something that would be specific to Fastify. I suspect this might be breaking more.

@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 6, 2018

@fhinkel all semver major PRs need review by the TSC. Thus, I added the request for review.

@mcollina this is indeed not specific to fastify, even tough I am pretty happy to see that CITGM did not find anything else. It is almost only an issue for the following case:

assert is used in production code including a custom message. This message is then tested for in their tests to verify everything worked fine.

I am going to split this into smaller steps to (a) make the userMessage backportable (that should be relied upon programmatically later on) (b) to accept further types in the message before and should be backported, which leads to (c) this change would be significantly smaller and easier to review.

I am also going to check the usage with Gzemnid even tough most entries will likely be false positives and filtering them is not that easy / requires a lot of manual work.

Adding the blocked label until I split this into the three pieces.

@BridgeAR BridgeAR added the blocked PRs that are blocked by other issues or PRs. label Sep 6, 2018
@cjihrig
Copy link
Contributor

cjihrig commented Sep 6, 2018

This won't impact code or lab. Thank you for checking though!

So far it was difficult to tell what the actual error was about if
there was only the user error. To overcome this, the user message
and the auto-generated message will now be visible at the same time.
@BridgeAR BridgeAR force-pushed the combine-user-and-generated-message branch from 8f9d266 to 89a9f00 Compare October 3, 2018 19:15
@Trott
Copy link
Member

Trott commented Nov 28, 2018

@BridgeAR Still want to see this one land If so, can you rebase?

@mcollina Anything that can be changed to make this acceptable to you? Or is your opposition to it a hard -1? (Personally, I'm undecided. I can see the reasons for doing it and I can see the reasons for not changing it.)

@BridgeAR
Copy link
Member Author

Closing for now. I'll open a new PR when I get to it.

@BridgeAR BridgeAR closed this Dec 19, 2018
@boneskull
Copy link
Contributor

user installs of Mocha are not impacted directly by changes to assert, so do whatever.

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. blocked PRs that are blocked by other issues or PRs. deprecations Issues and PRs related to deprecations. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants