Display JUnit Tags in Dev UI (Continuous Testing)

[ueberfuhr]

I strongly use JUnits @Tag annotation to organize my tests, and I think this could be helpful to display them in the Dev UI. So I added this feature and a non-persistent checkbox to hide the tags, if needed.

See these screenshots:

(Q is the shortcut for the io.quarkus.test.junit.QuarkusTest tag, so the user can see which test is a Quarkus test, and which one isn't.)

Hint:
The Vaadin Grid seems to recycle components, so the <qui-badge> too. However, this component is not implemented recyclable, which leads to inconsistent rendering. I have created a <qui-recyclable-badge>, that we can remove when the original badge is fixed. (see PR: qomponent/qui-badge#4)

What do you think - is this a helpful feature?

[quarkus-bot]

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

• title should preferably start with an uppercase character (if it makes sense!)

_{This message is automatically generated by a bot.}

[gsmet]

Sounds like an interesting addition. Can you filter on them?

/cc @phillip-kruger

[phillip-kruger]

Thanks @ueberfuhr - This is great. Let's wait for #42997 to be merged and then rebase this PR on top of that, so that you can use the badge that you fixed from qomponent.

[ueberfuhr]

Sounds like an interesting addition. Can you filter on them?

Currently - no. But I could give it a try, if you confirm.

Suggested Solution

I would not filter the results in the UI, but allow to restrict the test execution to a couple of selected tags, which would increase test performance.

The Quarkus Test Runtime allows to set application properties to include and exclude tags:

quarkus.test.include-tags=...
quarkus.test.exclude-tags=...

This leads to an initial configuration of the JUnit Test Runner that we could derive during runtime.

Further affected classes (first analyzation):

• io.quarkus.devui.deployment.menu.ContinuousTestingProcessor
• io.quarkus.devui.runtime.continuoustesting.ContinuousTestingJsonRPCService
• io.quarkus.dev.testing.ContinuousTestingSharedStateManager.State

[gsmet]

Oh my question was just about being able to filter on a tag in the UI if you have a lot of tests (i.e. you click on a tag and only the tests with this tag are displayed and then you can drop the filter). But I'm not sure it makes sense?

[ueberfuhr]

IMHO: Such a client-side filter would be nice, but searching then should not only be limited to tag(s), but also to test classes and test names. Such a search form would be a new requirement.

Executing only tests with a given tag would filter the results in the UI too, but the filter then is server-side and more performant when repeating the tests. But I'm not sure if this is part of this PR, or if I should do this in another PR as a separate feature.

In summary, I would say:

• this PR should only deal with the tag rendering in the DEV UI
• another Issue/PR might allow to only execute tests with a given tag (or given tags)
• another Issue/PR might introduce a filter form in Dev UI

Who can decide? 😉

[phillip-kruger]

I agree. Let's get this PR in, and then we can look at more features. The client side filter should be easy to do.

[ueberfuhr]

#42997 is merged now, so I'll fix my code ASAP (tomorrow morning).

[phillip-kruger]

Let me know when you are ready for a review

[phillip-kruger]

Thanks !

[phillip-kruger]

@ueberfuhr can you squash your commits into one please. Thanks

[phillip-kruger]

If there are no tags, can we disable the option to display tags and have the default to not display them ?

[ueberfuhr]

If there are no tags, can we disable the option to display tags and have the default to not display them ?

Yes, we can. 🙂 However, this needed a little refactoring of the QwcContinuousTesting class, because all the information about the results (incl. filtering by obj.test === true) are necessary when rendering the menu bar. Have tested this with 2 of my projects.

If I only have tests without any tag, it looks like this:

As soon as I introduce at least one tag:

[ueberfuhr]

@ueberfuhr can you squash your commits into one please. Thanks

Sure, done.

[ueberfuhr]

I did a small change based on the findings from #43067.

[gsmet]

@brunobat not sure what's going on but OpenTelemetryInjectionsTest has started to become extremely flaky.

[brunobat]

@brunobat not sure what's going on but OpenTelemetryInjectionsTest has started to become extremely flaky.

@gsmet created this: #43142

[ueberfuhr]

@gsmet, is this PR now ready to merge, or is anything missing yet?

[gsmet]

Nice work!

There's just one last micro thing and then it's good to go.

[maxandersen]

Oh nice one. Tags is underrated so nice to see it in Devui.

Should work nicely with https://quarkus.io/guides/getting-started-testing#running-specific-tests

Maybe a thing for the list of devui improvements for insights (or future one) @phillip-kruger

[phillip-kruger]

Yes very cool. I'll show this on insights

[ueberfuhr]

@maxandersen @gsmet - for filtering tests for execution or for rendering, I've created #43208 for a discussion and a decision. 🙂

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit d17d9ca.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ Native Tests - HTTP

📦 integration-tests/rest-client-reactive

✖ io.quarkus.it.rest.client.BasicTestIT.shouldCreateClientSpans - History

• expected: <1> but was: <2> - org.opentest4j.AssertionFailedError

org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
	at io.quarkus.it.rest.client.BasicTest.shouldCreateClientSpans(BasicTest.java:216)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at io.quarkus.test.junit.QuarkusTestExtension.interceptTestMethod(QuarkusTestExtension.java:810)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

[gsmet]

Awesome contribution, thanks!