Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[buckminster-dev] Re: Executing JUnit tests with headless Buckminster

Hi Achim,

I would be very much interested in helping and testing. Count me in.

Let's figure out a way to make the code available.

I like the fragment approach for plug-in projects, Oisin is talking about; but that wouldn't work for standard java projects, though.

I don't mind Git, but perhaps the Eclipse Git integration hasn't reached production quality yet (feedback)? If we decide on a distribution platform, I'll be happy to make my Buckminster plug-ins available in the same way. Personally, I was thinking about Google Code; but I'm not married to the idea!

Best regards,
 Dann


Achim Demelt wrote:
Dann,

My goal is to execute standard JUnit launch configurations with Buckminster headless, i.e. you define your tests in whichever way you like. If you're able to execute them in your workspace using "Run As/JUnit Test...", you only need to export the launch configuration and invoke Buckminster headless like this:

buckminster -data /path/to/headless/workspace junit -config test.launch

If that works out as expected, I'd like to contribute this to the Buckminster project. I will post appropriate patches to https://bugs.eclipse.org/bugs/show_bug.cgi?id=243293

That being said, it's still a long way to go. You'll stay up-to-date by CC'ing to the bugs. I'm reading between the lines that you'd be willing to help me with testing? ;-)

Regards,
 Achim

Dann Martens wrote:

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







Back to the top