| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Review requested:
|
Sorry, something went wrong.
|
ping @nodejs/test_runner can someone review this please? |
Sorry, something went wrong.
There was a problem hiding this comment.
I think this is a change we should make. I left a couple high level comments that I think could make the implementation a bit cleaner.
Sorry, something went wrong.
There was a problem hiding this comment.
I would like to get rid of this if possible. Each Test object now has a harness field that can be used to hold this "process level state." It is only used on the root test, and is currently initialized in harness.js but there is no reason it couldn't be initialized in the Test constructor. I have considered giving every Test a reference to the root test for a while now - I think that could simplify some things, including this.
We could put the counters object in the harness since it has the same scope as the other pieces of data that are stored in it. Then, instead of tracking all of the tests in a Set, every test could update the counters directly via this.root.harness.counters.
I think this would also get rid of the need for omitFromCounters because each test/suite would be doing its own updating (or not updating) of the counters.
Sorry, something went wrong.
There was a problem hiding this comment.
I like that suggestion very much
Sorry, something went wrong.
There was a problem hiding this comment.
Maybe we should have a type field on Test and everything that extends from it. We could differentiate between tests, suites, hooks, etc.
We could also use Symbol.toStringTag instead of a normal property or instanceof (although that one is probably a bigger perf hit).
Sorry, something went wrong.
There was a problem hiding this comment.
isnt this what I did? not sure what else are you suggesting?
Sorry, something went wrong.
There was a problem hiding this comment.
I was suggesting adding it to Test and all of the classes that extend Test. Right now it's only on Suite.
Sorry, something went wrong.
There was a problem hiding this comment.
I do not currently see any usage for that, but even if we want that just for the sake of simplifying code it should probably happen in separate PR
Sorry, something went wrong.
There was a problem hiding this comment.
I think it's worth keeping a count of the suites as well.
Sorry, something went wrong.
Sorry, something went wrong.
In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
…philnash In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
| Back | FazBrowse Home | New Git URL |
Fixes: #46762
this also introduces a property on the TAP yaml output to allow distinction between a suite and a regular test