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

Expose test.speed (or slow value) in reports (at least JSON) #4226

Closed
brettz9 opened this issue Apr 10, 2020 · 1 comment · Fixed by #4434
Closed

Expose test.speed (or slow value) in reports (at least JSON) #4226

brettz9 opened this issue Apr 10, 2020 · 1 comment · Fixed by #4434
Labels
area: node.js command-line-or-Node.js-specific area: reporters involving a specific reporter status: accepting prs Mocha can use your help with this one! type: feature enhancement proposal

Comments

@brettz9
Copy link

brettz9 commented Apr 10, 2020

Is your feature request related to a problem or a nice-to-have?? Please describe.

Relative to my purposes to allow precise badge-making from Mocha reporters that takes into account test speed/slow , it is a problem.

Describe the solution you'd like

I'd like for test.speed to be recorded in JSON results (and/or the slow value associated with the file as a whole and individual tests).

Currently, when I build a badge (here based on a template showing all of the various possible meta-data) from the mocha-badge-generator reporter, I can utilize information from a JSON file saved from a Mocha JSON reporter:

badge-template

However, the number of "fast", "medium", and "slow" tests do not take into account whether individual tests allowed for slower speeds (via calls to this.slow()) nor does it take into account if the default slow value (of 75ms) was changed for the original tests (I have instead needed to base the notion of slow on config repeated at runtime for this after-the-fact badge maker about what constitutes "slow" where I followed your algorithm for considering "medium" as half of "slow").

But if I had access to the slow value for each test (or whether a test was considered "slow", "medium", or "fast" when the test report was built), I could have my totals take into account expectations by the test makers.

In addition to speed (or slow) information, timedOut (and maybe sync too) would be useful to report also, so that reporters can aggregate information on such test types, counting for example how many tests failed because of timing out.

Describe alternatives you've considered

Where tests have to run separate times or otherwise have to act on reports previously generated, there are not really options here that I can think of.

Thanks!

@brettz9 brettz9 added the type: feature enhancement proposal label Apr 10, 2020
@boneskull boneskull added status: accepting prs Mocha can use your help with this one! area: reporters involving a specific reporter labels Jun 10, 2020
@boneskull
Copy link
Contributor

Thanks. Adding fields to the json reporter shouldn't be too bad.

If we can add some top-level metadata about Mocha's options, that'd be good. As @brettz9 notes, this could be useful.

@boneskull boneskull added the area: node.js command-line-or-Node.js-specific label Jun 10, 2020
outsideris pushed a commit that referenced this issue Sep 13, 2020
* issue 4226 : add print speed in json

* add print speed json-stream and json-stream.spec.js

* add print speed json-stream and json-stream.spec.js

* add pass test case in json.spec.js

* Update test/reporters/json.spec.js

Co-authored-by: Christopher Hiller <[email protected]>

* Update test/reporters/json.spec.js

Co-authored-by: Christopher Hiller <[email protected]>

* Update test/reporters/json.spec.js

Co-authored-by: Christopher Hiller <[email protected]>

* remove the testSpeed

Co-authored-by: Christopher Hiller <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: node.js command-line-or-Node.js-specific area: reporters involving a specific reporter status: accepting prs Mocha can use your help with this one! type: feature enhancement proposal
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants