[buckminster-dev] Re: Executing JUnit tests with headless Buckminster

[Dann Martens <dann@xxxxxxxxxxx>]

Hi Achim,

Hope springs eternal :)

I'm currently reworking my set of Buckminster plug-ins to work with 
Galileo. I hope to have them available by the end of Q3 2009.

I'd like to subscribe to your plug-ins; how can I get access to them? 
How are you handling the test reports? Are there any restrictions on how 
the tests are organized in the workspace? E.g. a src-test folder in the 
same project, or an additional .-test project for each tested project?

Best regards,
 Dann

Achim Demelt wrote:
> Hi Dann,
>
> Thanks for your support! Fortunately, Thomas participated both passionately 
> and factually in the discussion in 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=278844 . It seems we really 
> get a chance to do try this separation in the 3.6 timeframe!
>
> I'm about to finish the first stage of the refactoring. I guess that by the 
> end of the week I'll be able to run some tests.
>
> Regards,
>  Achim
>
> Dann Martens wrote:
>
> > Hi Achim,
> >
> > I have had exactly the same experience on a related front, and had to
> > resort to exactly the same strategy: duplicating code from the internal
> > code base.
> >
> > Unfortunately, I have already requested for a better decoupling of the
> > UI and the core (more than two years ago), but my request has fallen
> > onto deaf ears.
> >
> > I think we just need to become more vocal on the issue, as I fear their
> > attitude in resisting is really starting to stifle innovation on the
> > platform. I find that refusal hard to accept in the background of the
> > nasty roller coaster ride the p2 component is forcing an entire
> > community to sit through.
> >
> > Your request is reasonable on all accounts: (1) the code should be
> > refactored regardless, (2) improved layering improves re-use and (3) the
> > platform should welcome innovation.
> >
> > Still, I would not hesitate to take the difficult road already at this
> > juncture, because it is only the result which counts for others relying
> > on your work. Your effort in doing so is clearing the path for others to
> > innovate, as well. You shouldn't abandon your effort because of the fear
> > to throw stones at 'sacred houses'.
> >
> > My guess is that it only stands a chance to happen on the e4 track,
> > since the client-server model is pivotal to the architecture.
> >
> > Anyone who understands diplomacy and politics enough to open doors to do
> > this sooner can count on my support in terms of contributing patches.
> >
> > Best regards,
> >   Dann
> >
> >
> >
> >
> >
> >
> > Achim Demelt wrote:
> > > Hi Thomas,
> > >
> > > Over the weekend I have experimented with running JUnit tests from
> > > headless Buckminster. I wrote a new headless command that launches tests
> > > from within the workspace in a separate VM. On the positive side,
> > > everything went fine and I was able to run tests defined in the
> > > workspace. On the negative side, I basically duplicated code from JDT's
> > > JUnit plug-in.
> > >
> > > I'd love to reuse jdt.junit code, but unfortunately the JDT team has
> > > chosen *not* to separate the JUnit launching part from the UI part.
> > > Installing a whole bunch of UI stuff into headless Buckminster didn't
> > > seem like a good idea to me. So I went for copying a stripped down
> > > version of the JUnit execution code because the actual amount of code
> > > needed was relatively small.
> > >
> > > Then I started looking into PDE JUnit testing, and that's where things
> > > are beginning to get ugly. Again, PDE's JUnit launching code is happily
> > > coexisting with UI code in the same plug-in. Launching an equinox runtime
> > > to execute JUnit plug-in tests is not exactly a walk in the park, so I
> > > doubt that code duplication is a viable approach here.
> > >
> > > Ultimately, I would want to be able to read JUnit launch configurations
> > > from a file and execute them in Buckminster headless. This way, the user
> > > can specify VM args, equinox configurations, etc. for his tests. But this
> > > requires Buckminster to understand all parameters of JDT's and PDE's
> > > launch configurations.
> > >
> > > In my eyes, the only reasonable way for a solid JUnit integration in
> > > headless Buckminster would be to reuse JDT's and PDE's JUnit launching
> > > code. This would require the JDT and PDE teams to separate their core
> > > code from their UI code and put it into separate bundles. I guess there's
> > > no way this is going to happen if *I* file a bugzilla, even if I attach a
> > > patch.
> > >
> > > Thomas, what's your view on this? Do you see alternatives? Would you be
> > > able to persuade the JDT/PDE teams to do such a refactoring?
> > >
> > > Cheers,
> > >  Achim