| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
typo: then → than
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-commit/9765/ |
Sorry, something went wrong.
There was a problem hiding this comment.
Can you undo this block of changes.
Sorry, something went wrong.
There was a problem hiding this comment.
the JSDocs?
It's usefull for people with IDEs that can parse these (VSCode / Webstorm)
Sorry, something went wrong.
There was a problem hiding this comment.
Other than lib/punycode.js which is vendored, there are only 9 @param matches in all of lib, src, and test. It's more consistent to drop them.
Sorry, something went wrong.
There was a problem hiding this comment.
This code should live in test/parallel/test-common.js I think.
Sorry, something went wrong.
There was a problem hiding this comment.
didn't see that one...
Sorry, something went wrong.
|
I think this needs a documentation update. |
Sorry, something went wrong.
|
Docs added, nit's addressed. @cjihrig I'd rather keep the JSDocs, unless you have a strong objection. |
Sorry, something went wrong.
|
I wouldn't say strong objection, but definitely -1. |
Sorry, something went wrong.
Gone. |
Sorry, something went wrong.
|
Could you point to somewhere that this would be better suited for rather than the explicit number of calls? |
Sorry, something went wrong.
|
I generally think this is a bad idea because if something is being called more times than you expect you've probably got a bug. |
Sorry, something went wrong.
|
Sorry, something went wrong.
I tend to agree, but some things are either OS dependent or non deterministic. In those cases we tend to skip the mustCall all together which IMHO is worse. |
Sorry, something went wrong.
|
-1 I don't think it is a good idea to reuse the same parameter (or even the same function) for this. |
Sorry, something went wrong.
|
@Fishrock123 ... this came up with regards to adding mustCall() around a data event handler, which could be reasonably called any number of times. @mscdex ... the other option I had in mind was a common.mustCallAtLeast(n) method that would allow a minimum number to be specified. |
Sorry, something went wrong.
|
@jasnell I would much prefer a separate method so that the intention is clear. |
Sorry, something went wrong.
There was a problem hiding this comment.
-0 from me. I dislike magic values. I prefer that things in common have simple, self-explanatory, and intuitively obvious interfaces. This adds more cognitive overhead, especially for newcomers.
Sorry, something went wrong.
There was a problem hiding this comment.
Nit: This documentation change results in a confusing run-on sentence:
If the returned function has not been called exactly expected number of times, or at least once if
expected === '+', when the test is complete, then the test will fail.
Would be better as something like:
If the returned function has not been called exactly expected number of times when the test is complete, then the test will fail. If expected is '+'`, then the test must run at least once.
Sorry, something went wrong.
Eh, still pretty +/-0 on it. I think there's enough API surface area in common and we quickly reach a point of diminishing returns. Moreover, I'm not really sure this is solving a very common problem. I imagine it's mostly for data callbacks in tests that are called once but could theoretically be called more than once. However, those almost never need to actually be wrapped to make sure they're called because they usually have something like data += chunk and then the value of data is checked somewhere, so you don't really need to check that the callback was called. The test will fail if it wasn't. (Will there be a small number of empty callbacks for data that we want to check? Sure. Is it worth adding a whole other function to the common monolith for it? I doubt it.) But if others feel this has big value, I won't stop it. |
Sorry, something went wrong.
|
Replace magic '+' with mustCallAtLeast PTAL |
Sorry, something went wrong.
|
P.S. why don't we adopt something like sinon. |
Sorry, something went wrong.
Biggest reason is probably because no one's bothered to do it yet. That said, a PR adding sinon very well might not get accepted. Speaking only for myself, I have grown wary of things that raise the barrier to entry for people working on tests. So to the extent that we avoid extra tools and unneeded abstractions in the common module, I'm happy. But that said, if the benefit would be considerable and obvious, I'd be for it. Others in @nodejs/testing might have other opinions. |
Sorry, something went wrong.
|
Pre land CI: https://ci.nodejs.org/job/node-test-commit/10013/ |
Sorry, something went wrong.
|
Should this land on v6.x? |
Sorry, something went wrong.
Sure. It's a semver-minor change in the test harness. |
Sorry, something went wrong.
PR-URL: #12935 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: #12935 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
added common.mustCallAtLeast for calling more than minimum times.
Checklist
Affected core subsystem(s)
test