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: Add assert.rejects. #1238

Merged
merged 2 commits into from
Jan 7, 2018
Merged

Conversation

rwjblue
Copy link
Contributor

@rwjblue rwjblue commented Dec 17, 2017

Closes #1204

Copy link
Contributor

@platinumazure platinumazure left a comment

Choose a reason for hiding this comment

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

This looks like a great start! Are there any tests that show assert.rejects causing a test failure if the promise is fulfilled? I only gave this a cursory view as my plane landed, so apologies if I missed something.

@rwjblue
Copy link
Contributor Author

rwjblue commented Dec 18, 2017

@platinumazure - Thanks for reviewing! You are absolutely right, I was actually somewhat confused about how that worked as I'm used to failing assertions failing CI (which is to be avoided), but a testing framework has to creatively work around that to ensure that its failures are correct too. I did a bit of digging after your comment to see how this was handled for things like assert.throws or assert.ok, and figured out how it works (inverting assert.pushResult's result value).

tldr; I just pushed an update with tests around when assert.rejects fails.

@platinumazure
Copy link
Contributor

I've taken another quick look and it looks promising. I'll give it a full review this week. Naturally, I'll also want @trentmwillis to take a look as well. Thanks for your hard work!

@rwjblue
Copy link
Contributor Author

rwjblue commented Dec 18, 2017

looks promising.

Hehe. Thank you, got a good chuckle out of this pun this morning. 😝

@Krinkle
Copy link
Member

Krinkle commented Dec 18, 2017

I assume we don't want to support expected as string because it creates ambiguity with the optional message parameter. I don't have a specific suggestion here, but I do think it warrants better documentation than currently provided.

As-is, the documentation tells me the following:

  • expected is a comparable for the rejection value.
  • Function and RegExp type values are special cases, other types are compared directly to actual (such as an Error instance).

However, current code supports object as the only "regular" comparable value type. Any other value (except string) silently falls back to result = false, that's definitely a problem.

I understand string is a problem because of ambiguity with the optional message parameter. I also understand that we (I think?) discourage throwing things that aren't objects. But in that case we shouldn't showcase it in the documentation. The first usage example is currently Promise.rejects("error").

Two minor suggestions, if we indeed want to discourage throwing non-objects:

  • Remove non-object rejection example from documentation.
  • Make sure that assert.rejects explicitly fails when expected is of unsupported type (with unit tests to confirm). The missing else case in the current code suggests that at least number and boolean types would result in silent or less-obvious failure.

};

assert.rejects(
Promise.reject("error"),
Copy link
Member

Choose a reason for hiding this comment

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

(*)

@rwjblue
Copy link
Contributor Author

rwjblue commented Dec 18, 2017

Thanks for the review @Krinkle! I just pushed some changes which (assuming I understood your concerns properly) should address your bullet points.

Specifically:

  • cleaned up the documentation a bit to make it clearer what each expectedMatcher type actually did
  • refactored the implementation around function's for the expected value so that we can properly be aware of the difference between "invalid expected type" vs "matcher function returned non-true"

Let me know what you think!

Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

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

Overall, looks good to me. Just some minor things.

@Krinkle, when you have a moment, can you review again to verify your concerns were addressed? (Looks to me like they were.)

| name | description |
|--------------------|--------------------------------------|
| `promise` (thenable) | promise to test for rejection |
| `expectedMatcher` | Rejection value matcher |
Copy link
Member

Choose a reason for hiding this comment

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

This name is inconsistent with the function signature given. I'd prefer we use expectedMatcher throughout as it makes more sense semantically.

specific set of circumstances, use `assert.rejects()` for testing and
comparison.

The `expected` argument can be:
Copy link
Member

Choose a reason for hiding this comment

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

expected -> expectedMatcher

```js
QUnit.test( "rejects", function( assert ) {

assert.rejects(new Error("some error description"));
Copy link
Member

Choose a reason for hiding this comment

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

This is an invalid example, right?

"`rejectionValue.toString()` contains `description`"
);

// Using a custom error like object
Copy link
Member

Choose a reason for hiding this comment

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

Nit: inconsistent indentation.

src/assert.js Outdated
message = expected;
expected = undefined;
} else {
message = "rejects does not accept a string value for the expected argument.\n" +
Copy link
Member

Choose a reason for hiding this comment

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

Can we put assert.rejects() does not accept a string value...? I think it is just a bit clearer/more helpful.

@trentmwillis
Copy link
Member

@rwjblue, no pressure, but do you think you'll update this soon? I'd like to see it in the next release if possible but it can always be in the one after as well 🙂

@rwjblue
Copy link
Contributor Author

rwjblue commented Jan 7, 2018

@trentmwillis - Thanks for the review! I cleaned up the docs and fixed the error message, I believe that addresses all of the outstanding review comments.

@trentmwillis trentmwillis merged commit 5db78e2 into qunitjs:master Jan 7, 2018
@trentmwillis
Copy link
Member

Thanks a bunch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants