-
-
Notifications
You must be signed in to change notification settings - Fork 305
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
[readme] improve t.throws
/t.doesNotThrow
documentation
#541
Conversation
* Described method behavior when "expected" parameter is a string. * `throws`: Described method behavior when "expected" parameter is an object (i.e. validation object). * Added usage example for when expected parameter is a regex. Fixes #540.
Codecov Report
@@ Coverage Diff @@
## master #541 +/- ##
=======================================
Coverage 74.15% 74.15%
=======================================
Files 19 19
Lines 766 766
Branches 146 146
=======================================
Hits 568 568
Misses 198 198 Continue to review full report at Codecov.
|
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, this looks great! Mind making the same changes to doesNotThrow
, just below?
(There aren't any other files to update; and other than throws/doesNotThrow, let's save additional updates for another PR)
OK sure. Give me 24 hours and I'll push a new commit to this PR.
OK noted on all. |
OK I just pushed a second commit with the edits to I also added some of the existing verbiage from |
t.throws
/t.doesNotThrow
documentation
Great! Give me a few more days and I'll add that validation object example we discussed. If new issues are submitted related to this area, feel free to tag me (or this PR, or my commits, or whatever), and I can take a look. |
- [New] add `.teardown()` on `t` instances (#546) - [New] Include name of test in log when test times out (#524) - [Refactor] avoid reassigning arguments - [Refactor] remove unused line, unneeded var initialization; add missing `new` - [Refactor] remove use of legacy `exports` - [Refactor] Avoid setting message property on primitives; use strict mode to catch this - [Refactor] generalize error message from calling `.end` more than once - [Refactor] use `call-bind/callBound` instead of `function-bind` directly - [readme] improve `t.throws` documentation (#541) - [readme] Another way to create custom reportersA (#556) - [readme] remove long-dead testling-ci badge - [readme] add `tape-describe` to 'other' section (#523) - [readme] remove travis badge; add actions and codecov badges - [eslint] remove useless regex escapes - [eslint] fully enable `@ljharb` eslint config - [meta] do not publish github action workflow files - [meta] add `safe-publish-latest`; use `prepublishOnly` script for npm 7+ - [meta] run `aud` in `posttest` - [Deps] update `glob`, `is-regex`, `object-inspect`, `resolve`, `string.prototype.trim` - [Dev Deps] update `eslint` - [actions] use `node/install` instead of `node/run`; use `codecov` action - [Tests] exclude examples from coverage - [Tests] ensure bin/tape is linted - [Tests] make `stripFullStack` output an array of lines, for better failure messages - [Tests] handle stack differences in node 15 - [Tests] add test case for #519 for test.comment() in createStream/objectMode context
v4.14.0 - [New] add `.teardown()` on `t` instances (#546) - [New] Include name of test in log when test times out (#524) - [Refactor] avoid reassigning arguments - [Refactor] remove unused line, unneeded var initialization; add missing `new` - [Refactor] remove use of legacy `exports` - [Refactor] Avoid setting message property on primitives; use strict mode to catch this - [Refactor] generalize error message from calling `.end` more than once - [Refactor] use `call-bind/callBound` instead of `function-bind` directly - [readme] improve `t.throws` documentation (#541) - [readme] Another way to create custom reportersA (#556) - [readme] remove long-dead testling-ci badge - [readme] add `tape-describe` to 'other' section (#523) - [readme] remove travis badge; add actions and codecov badges - [eslint] remove useless regex escapes - [eslint] fully enable `@ljharb` eslint config - [meta] do not publish github action workflow files - [meta] add `safe-publish-latest`; use `prepublishOnly` script for npm 7+ - [meta] run `aud` in `posttest` - [Deps] update `glob`, `is-regex`, `object-inspect`, `resolve`, `string.prototype.trim` - [Dev Deps] update `eslint` - [actions] use `node/install` instead of `node/run`; use `codecov` action - [Tests] exclude examples from coverage - [Tests] ensure bin/tape is linted - [Tests] make `stripFullStack` output an array of lines, for better failure messages - [Tests] handle stack differences in node 15 - [Tests] add test case for #519 for test.comment() in createStream/objectMode context
Hi Jordan,
Sorry for the delay on this. Per our discussion (in issue #540), in this commit I have edited the README to describe the following:
t.throws()
when theexpected
parameter is a string.expected
parameter fort.throws()
can be a validation object (just like Node'sassert.throws()
).Have a look and let me know if anything is incomplete or inaccurate.
For now, due to time constraints, I omitted an example of validation object usage, and simply added a link to the Node documentation. I'd very much like to add such an example (as they've done on the Node documentation page), but I'm out of time today, and might get busy with work tomorrow for the next week or so. I can try to keep you posted here on that schedule. But it may be the case where you want to merge these edits now, and I open a new pull request next week which adds the validation object example.
Two more questions that we might want to address now (or earmark for future discussion):
Are there files other than the README that should be updated with this information? If so, I can do that if you want (either in this pull request or a separate pull request in the future).
In the README, should other methods be updated with similar information? i.e. are there other methods with an
expected
parameter that cannot be a string? If so, I can do that if you want (either in this pull request or a separate pull request in the future).--Carl