Greetings!
Hey @etorreborre, I've just encountered a bug which I traced back to a bug reported in 2015.... #440
I have a case of "double-reporting" from
JUnitPrinter
the biggest problem: I don't seem to have the stack frame of the parent runner (google/bazel), so I can't use the same trick to prevent reporting
Anything I could reproduce on my side?
I'll try, but it's involved... took me half a day to printf-debug it on the bazel side
then I ended up tracing it to JUnitPrinter
then imagine my manic laughter when I found the comment about double-reporting, which was reported by Orr Sela, a guy who worked on Bazel at Wix before Ittai :)
small world :-)
hah indeed
I tried dumping the stack trace, but everything is contained to specs, I don't see any external runners :(
I wonder if you could support some flag to prevent the sink from... sinking?
this would probably be a good last-resort solution for preventing notification?
if you pass a dummy notifier as a command-line argument only that one would be used for reporting but I don’t see how that would solve your issue
this was literally just a thought I had :DD
was about to ask if there was a NullNotifier available.
the bazel junit support uses a listener to get callbacks from the runner, to create the report
there’s a
org.specs2.reporter.ConsoleNotifier which you can pass with notifier org.specs2.reporter.ConsoleNotifier
if nothing is passed to the command line, what is the default notifier used with junit?
hmm, that is a wrong question to ask, one sec
grr, must run, will pick this up later
If you have any thoughts about a general mechanism to suppress notifications, that would be great too :)
I now realize I have 2 issues... seems that bazel runner starts a thread before it actually executes the underlying junit runner
so top of the callstack is a mere
java.lang.Thread.run(Thread.java:748)
the only way to know I'm being called from the runner is getting the class name of the
RunNotifier instance
I had a proposal of adding a new parameter somewhere in
Env to skip notification, if it was set
but seems this wouldn't work in the "basic" case, where I have no control over the command line arguments
so... plan b is a predicate on the Class name :( It feels really ad-hoc, but I don't see any other option right now
If I have a sealed trait with a couple of impls, what's the most elegant way to asser twith specs2 that a
List[mytrait] are all of a given subtype?
haveClass
SONOFABITCH! I fixed it! It seems #440 fixed the issue, but it got broken some 2 years ago when everything was
Fold-ified! :sweat_smile:
It actually WAS a bug all along! 440 effectively does nothing in v4, because by the time
isExecutedFromJUnitCore evaluated, it's running on its own thread! There's no trace back to the original calling method!
I'll send a PR, this actually would solve 2 major issues we're having! Wow :)
This is where the hacks start hitting really hard, sorry about that (and you can thank the JUnit team for giving us 2000 ways to integrate with the library
how did you fix this issue?
I pulled out the
isExecutedFromJUnitCore to the outer scope, so I evaluate it when sink is called
so the callbacks close over the already evaluated value
this should work, as sink is being called by the printer when everything initializes, so we should be good :)
I also added another
isExecutedFromBazel, just in case, but the Core one handles it too
Ok I see.
this explains why we've been seeing weird reports from the printer too, sometimes it would print "OK (0 Tests)"
Anyway, I'll tidy this up a bit and send a PR.
yes because he’s confused about starts and stops. But I really wish the junit reporting worked the same on all platforms
ok thank you I will publish a new release afterwards
BTW, I've been meaning to ask, what do you use to develop specs2? When I try to open it in IntelliJ, everything is red
(I import the sbt file)
I gave up and opened it in VSCode :)
I’m using IntelliJ but I always deactivate the green [T] at the bottom right (type-aware highlighting)
aah.. yeah, that's smart :)
I must say I deactivated that option a long time ago, it never worked for me :-)
Awesome. Well, gonna hit the bed. Thanks again, I'll send that PR tomorrow.