You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.
I'm trying to design a JUnit4 Rule and have run into an issue with tests using Burst, because the Description passed to my rule returns null from getTestClass().
It looks like this line is the source of the Description in question, as it passes a custom string instead of a className.
Would Burst be open to fixing this? Something like:
Is sufficient for my use case, though it does change the result of Description.getDisplayName(). If that works I'm happy to send a PR, otherwise are there other approaches you might be open to?
The text was updated successfully, but these errors were encountered:
I think this is probably fine, but it's been so long the nuances of descriptions are definitely lost on me. The only real concern, I think, is the effect on the IDE experience.
Yeah, I'm not sure if there's a specific format for the second argument that would be most-correct, but seeing as nothing's blown up with the malformed className I'd hope IDEs can handle a change like this? 🤞
I'm trying to design a JUnit4 Rule and have run into an issue with tests using Burst, because the
Description
passed to my rule returns null fromgetTestClass()
.It looks like this line is the source of the
Description
in question, as it passes a custom string instead of aclassName
.Would Burst be open to fixing this? Something like:
Is sufficient for my use case, though it does change the result of
Description.getDisplayName()
. If that works I'm happy to send a PR, otherwise are there other approaches you might be open to?The text was updated successfully, but these errors were encountered: