Integrating into JUnit results

Hello Carson,

As far as I understand, for JUnit integration to work with Gosu classes,
they need to implement the Java PSI API interfaces (PsiClass and PsiMethod).

Alternatively, you can implement your own test runner with a separate run
configuration type.

I'd like to integrate tests written in Gosu into IJ's JUnit support.

Any pointers where to start?  I couldn't find anything along these
lines in the Groovy plugin...

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Interesting.

So when I right click on the class itself, it works (well, see below.)  However, when I try to run a package it is not picked up.  I can investigate that problem later.

Next step is to get the Gosu environment up and running so we can correctly produce a class for the IntelliJ JUnit runner.  

Gosu is a "source-based" language in that everything is compiled at runtime, so there aren't any class artifacts sitting around for the class loader to just load up.  Instead, we've got our own classloader that needs to be around to resolve (and compile) Gosu classes.

I'll look into that, but of course any thoughts you have on the matter are greatly appreciated.

Thanks!

Carson

Hmm, well, looking at JUnitStarter, it looks like I'm snookered: I don't see a good spot to plug in another classloader.

Adding to the woe is the fact that gosu resources continue to live in the /src directory, rather than being copied into the /classes or /out directory.  

Hmmmm.

Cheers,
Carson

Maybe the right thing is to implement a Java agent.  It looks to me like that's what the groovy guys do.

Cheers,
Carson

Well darn it.

An agent will let me mutate a class that is being loaded or add a jar to the bootstrap classpath, but it won't let me resolve classes that aren't on the classpath.

So I find myself snookered again.

I could fork intellij and put in the very few hooks I need  (I can use an agent to start the thing and then I just need a way to change the classloader that IJ uses to load tests with) to make it work, or is that just a terrible idea?  (I'd like the Gosu plugin to work OOTB with IntelliJ, so if there is no chance of you guys accepting the patch back, I'll try to figure out another way to get there from here.)

Cheers,
Carson

Alright.  Who here wants to know how I ended up doing it?

Not pretty, but this kind of works:

I created an extension of com.intellij.execution.runners.JavaProgramPatcher to rewrite the main class for test invocation from JUnitStarter to my own starter.  

In my own starter, I created a new classloader that jacks in gosu classes (with a bit of tap dancing around initialization) and then spin up the usual JUnitStarter in that new classloader, so that our friends TestRunnerUtil, et al. end up being loaded in a class loader that knows about Gosu resources.

Really, really ugly, but at least its a minimal amount of ugly code.

Is there someone at IJ that would work with me to make the testing back end a bit more pluggable?  There are really only a few places I'd need a hook to avoid all this classloader insanity.

Cheers,
Carson

I feel like I need popcorn with a story like that :-)

Interesting though, thanks - I may end up having to do something similar shortly.

Cheers,
Colin

Did you just say "Cool Story, bro"?

;)

Hehe, pretty much, except with popcorn!

Hello Carson,

Anna Kozlova <anna.kozlova@jetbrains.com> is currently responsible for the
JUnit plugin. Feel free to ping her to discuss this in more detail.

Alright.  Who here wants to know how I ended up doing it?

Not pretty, but this kind of works:

I created an extension of
com.intellij.execution.runners.JavaProgramPatcher to rewrite the main
class for test invocation from JUnitStarter to my own starter.

In my own starter, I created a new classloader that jacks in gosu
classes (with a bit of tap dancing around initialization) and then
spin up the usual JUnitStarter in that new classloader, so that our
friends TestRunnerUtil, et al. end up being loaded in a class loader
that knows about Gosu resources.

Really, really ugly, but at least its a minimal amount of ugly code.

Is there someone at IJ that would work with me to make the testing
back end a bit more pluggable?  There are really only a few places I'd
need a hook to avoid all this classloader insanity.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"