-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Mention containers and tests that were ignored because of their tags #1514
Comments
I'm new, but I'd like to try this out. Do you mind if I give it a try? |
Hi @debugduck, I can't make that call. While I occasionally contribute, I'm not a member of @junit-team and can hence not decide what gets implemented and what doesn't. The team is currently working on the 5.3.0 release - let's hope they take a look at this issue over the next days. |
@debugduck, I cannot promise that we will include this feature, but I do think it stands a good chance for inclusion since "diagnostics" is an area in which we would like to make improvements in general. In light of that, I have added the "up for grabs" label. So feel free to submit a PR. Cheers, Sam |
Assigned to the General Backlog for the time being. |
@sbrannen I came across this issue looking for
There are two ways that I could think of approaching this.
I along with @logic-1 want to take a shot at this issue and similar issues in junit diagnostics (Mostly the ones summarised in #242 ). Please guide us here, we are new to open source but we would like to give it a try. |
Thanks for the detailed summary. I think (2) is not an option because it would require all test engines to be adapted and change the current behavior. As I currently don't have any idea how build tools or IDEs would display such information, how about we collect this information in |
Since junit already provide interface to use for build tools/ IDEs to gather result of each test method /containers , so they can create final test summary in whatever way they want to display. @sbrannen can you suggest something around this.? |
@sbrannen Is this issue still being worked on? Looks like it's gone silent and I'd like to have a go at it as it's |
@antimpatel, sorry for the belated reply. This somehow slipped under the radar. I tend to agree with @marcphilipp. At this point in time, we are not aware of considerable interest in having this information reported in builds or IDEs. Rather, we believe that logging filtered out containers and tests would be sufficient for an initial attempt at providing such diagnostic information to users. If we later determine that there is significant community interest in a formal reporting mechanism for this, we then might consider options # 1 and # 3 that you suggested. |
@RoryBlevins, I'm not sure if @antimpatel is still working on this or interested in continuing to work on this. So let's see if we receive a response from @antimpatel. |
👍 Feel free to point me in the direction of something else sensible for someone new to the project to pick up |
@RoryBlevins, see if there's anything in the following list that piques your interest: up-for-grabs If not, you can always look at open issues in one of the backlogs and ask on the issue if contributions would be welcome. |
@sbrannen, @marcphilipp, Yes would like to continue here. @marcphilipp As mentioned by you I need to collect data in Default Launcher, After browsing code here is what I have figured out, let me know if a better way exists, Since Root object is responsible for removing the methods with tags(considering only methods should be printed which are excluded not the tags), Approach: I can pass reason from TagFilter for both inclusion and exclusion, which will be available in filterResult object, and in Root, store(maybe a map with TestEngine) filter results of all excluded methods. which will be accessible in DefaultLauncher. Here We can not club filterResult only for TagFilter since we don't have any type in postDiscoveryFilter. |
Can we group the excluded |
@marcphilipp will do it and raise the PR for the same. |
Current Behavior: During execution of post discovery filters, tests which are excluded does not print any message/reason, which leaves developers to be unaware of reason for exclusion. Also No reason was passed from TagFilter class. Solution: Stores the Exclusion reason against the set of TestDescriptors and print this information after discovery phase. Passed the inclusion or exclusion reason to FilterResult for TagFilter. Issue: junit-team#1514
Tagging and filtering works great, but developers could be irritated when their test is not executed (because of a tag) and they don't know why (maybe being new to the code base).
Jupiter could print a message that tests were ignored because their tag was not activated. If these information are easy to gather without performance impact, it could even print some numbers, something like:
The text was updated successfully, but these errors were encountered: