-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Indicate when a test is started in test_runner #46727
Comments
Printing something probably won't work in all cases - specifically when running tests in parallel. |
we can emit an event on |
That would work fine for my use case; once #46045 is in I would like to switch to |
@connor4312 is this still needed by you? |
This would still be quite helpful to me and, I believe, most editor integrators. |
Hi. I would like to help on this. |
I have been looking into the files in lib/internal/test_runner. I went through Also to clarify, it's required to use a emit start event for reporters other than TAP i.e for dot and spec. I am finding this part confusing.
|
yes
why is it required? these reports print to stdout when the test has been completed, not when it starts |
emit a start event to show message just after a test/subtest start Fixes: nodejs#46727
Hello @MoLow. Thanks for the previous reply.
It's not required. My understanding was wrong back then. I have made a single line change and attached the draft PR. Here's the output that I am getting currently. Have added a "starting..." string. Would like to know if
|
Could you please guide me on tests. From looking into prev commits, current understanding is: need to add my test output to test/fixtures/test-runner/output Request your guidance here. Thanks. |
Small nit on the event name, I would name it (though I don't have the context to know if a comment is the right approach in general here 🙂 ) |
@sankalp1999 there is no intention to change to output of the TAP reporter. the requirement here (if I understand it correctly) is to add a subtest started event to the tests stream, this means the event will only be usable through the run API but not via one of the existing reporters |
Maybe I missed something, but why does the |
also, firing such an event without affecting the TAP output will not work with the current implementation and might require first moving to use another serialization method, as we discussed on other issues |
OK that makes sense. Having two separate events makes sense, but the fact that |
I agree |
Let's rename it then? It's not too late and now is the time |
I believe changing the reporter API is considered breaking at this point (but changing the textual output of a reporter is not). EDIT: Not saying we shouldn't do it though. |
Thanks @MoLow. I have made a test:begin (name_to_be_decided) event in the test_streams file since test:start is already being used. Not sure if I need to make changes in the textual output in the reporters as you mentioned "this means the event will only be usable through the run API but not via one of the existing reporters" |
I was going through the docs to see how I can write the setup option (edit:i meant arguments) in the run api in order to emit events. Can someone give me an example. I tried to import the TestsStream object so that I can make a setup function with calls to emit events (if that's how it is done). But for that, I would be using internals which I am not sure a user would be doing. So I guess it's wrong. Can you give one example on how I can setup custom events using run api. Now I don't know how that's supposed to be. It's not clear in the docs. Perhaps some examples can be added in the docs for this => On how to use the various options provided with the run api.
|
hi @MoLow . can you have look at the above comments. |
@sankalp1999 the doc changes make sense indeed |
emit a start event to show message just after a test/subtest start Fixes: nodejs#46727
What is the problem this feature will solve?
When running tests in an editor (like VS Code), users want to know what test is currently being executed. This is useful, so if a test is hanging for instance, it's easy to see what it is.
What is the feature you are proposing to solve the problem?
Currently, TAP output for a test like...
looks like this:
The "Subtest:` comment, and following assertion result, is only printed once the test completes. Two good alternatives would be to:
Subtest:
comment when the test is started, rather than when it finishes, or(The former is breaking for the way I handle logs in VS Code's runner, but this is due to my own hackery; not sure if any others will be affected)
What alternatives have you considered?
No response
The text was updated successfully, but these errors were encountered: