Unfortunately I’ve never been able to get test fragments working with PDE Build. There is an open Bugzilla entry on this, and maybe you could add a post saying that you’d be interested in a solution.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=181508

The more people that ask, the better.

Regards,

— Patrick

Your approach makes sense. The only alternative I see is to create some common test plug-in that could contain reusable test classes. This would eliminate the visibility leakage issue you have, but as you say it’s not really a big deal.

Thanks for posting this tip. I think it will help others trying to do fragment-based testing.

— Patrick

We’ve been using the fragment option for almost a year now. As you may recall you helped us to get our RCP app up and running. Anywho, in using fragments as containers for tests, I’ve found that it’s useful to have “Eclipse-ExtensibleAPI: true” in the manifest for the host plugin. By default this value is false. This allows fragments to contribute API to the host plugin and is useful if you want to provide utility classes and methods for testing that other test fragments can use.

For example:

ModelPlugin:
-SomeModel class

ModelTestPlugin:
-ModelTests class — extends TestCase and provides helper methods to create SomeModel objects
-SomeModelTest — extends ModelTests; just for completeness :]

PresentationPlugin:
-SomePresenter class

PresentationTestPlugin:
-SomePresenterTest class — extends ModelTests*

* Without specifying the “Eclipse-ExtensibleAPI: true” in the manifest for ModelPlugin, I would not be able to extend ModelTests in PresentationTestPlugin (would get compilation errors). Of course the disadvantage to this is that now PresentationPlugin is going to have visiblity to ModelTests, but that’s something I’m willing to live with. Perhaps there’s still a better way yet?

Cheers,
Nihal

Reference:
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

No problem. I’m glad you figured it out and that the fragments weren’t increasing your test times.

– Patrick

Thank you for your reply.

I found out why my tests had started to take longer, and it had nothing to do with the fragment change. When I made the big change, I moved everything into a new Eclipse workspace. I cloned all the project stuff from the old workspace, but I was not clever enough to also copy all of the Eclipse metadata. I mean, of course I could have copied all of it, but I was afraid that if I had done that I might have ended up retaining confusing, conflicting settings from the old project organization. In other words, I would have liked to clone only part of the metadata, but the prospect of trying to figure out which parts are which was daunting.

So of course I had to redo a bunch of settings from scratch. I forgot that in the old days I had customized the VM parameters for my test run, to give it much more memory than the default. When I duplicated that config setting in my new workspace the tests once again started running about as fast as they used to.

So now everything’s all great, and I’m really happy.

Thanks again for the cool tip. And I apologize for the “crying wolf”.

Cheers,
– arb

Can you tell me how your tests were structured before? Were they in the same plug-in as the code under test or in a separate test plug-in? If the tests were in the same plug-in, the extra time could be related to loading the fragment into memory, but I’m not sure.

It would be interesting to run those tests using a profiling tool to see where the extra time is going. I’d also be interested to know whether there is a scaling 50% increase in time for tests or whether there is simply a 10 second penalty.

I’ll try to look into this at some point but I’m pretty buried at the moment :-) If you find out anything, please let me know.

— Patrick