CODEWITHSUNDEEP
javamaveneclipse-plugintddosgi
JSlain
JSlain

Reputation: 576

Eclipse plugin + TDD?

How to do TDD while developping Eclipse plugins? Since PDE is a manifest-first approach, there's no such thing as 'test scoped dependency'.

Should i make another project on the side, which is maven-based? and adds the plugin project directly in it's buildpath? (since the plugin project isn't maven-based, it won't be in .m2). This doesn't seems like a great setup...

I've read somewhere that a plugin fragment could do the work, but i have to manually add Mockito or EasyMock to a custom repository? Or include it in the classpath inside that fragment? That doesn't seem pretty portable.

I'm getting used to Bndtools, but does it fit for eclipse plugins?

Also, i usually use Infinitest and MoreUnits, i guess the latter won't work if the tests are located in a second project?

Finally, i just read about Eclipse Tycho, which is a set of maven plugins to build eclipse plugins, would it be a suitable option, even if it's in the incubator?

Upvotes: 3

Views: 529

Answers (1)

Rüdiger Herrmann
Rüdiger Herrmann

Reputation: 20985

We have used test fragments in several projects for many years now and found it to be the most practical approach.

Because the fragment shares the same class loader as its host bundle, your tests can access internal packages and package-private methods just as if there was no OSGi container.

Fragments can even have a fragment.xml where you can contributes extensions for testing if neccesary.

The most annoying part of test-driven plug-in development are the PDE tests itself. As soon as your code under test requires the workbench to be running, test execuion slows down drastically. PDE tests start the Eclipse workbench to execute tests therein.

Therefore we strive to isolate our code from workbench code as much as possible. This allows us to write 'fast' plain JUnit tests whenever possible and only resort to PDE tests if absolutely necessary. Both test may reside in the same fragment and be distinguised by a maning pattern.

Test dependencies (JUnit, Mock libraries, matcher libraries, etc.) need to be provided through the target platform (along with other non-test dependencies). While mixing those dependencies may seem odd we haven't had any issues with it in paractice.

MoreUnit fits just fine into this setup. It can be configured (per project) to look for test/production code classes in specific source folders even if those reside in a different project.

Infinitest is probably not well-suited to execute PDE tests, just because their execution speed is slow and Infinitests is about executing fast tests frequently. But if it is possible to exclude PDE tests you may still be able to use it for plain JUnit tests.

For example, the Eclipse Extras project applies the described techiques - if you are interested you can explore the sources to see how they work in practice.

If you start from scratch, Bndtools is certainly worth considering. I've heard that the Bndtools developers use Bndtools to build Bndtools. AFAIK Bndtools has no editing support for plug-in artifacts like plugin.xml. But maybe you can use the PDE plug-in editor along with Bndtools to edit extension and extension points.

In a typical Bndtools project, your production code and test code reside in different source folders within the same project, much like a maven project. However, the test source folder is not included in the resulting bundle.

The downside of having production and test code within the same project is that test dependencies are visible from the production code. This is because both source folders share the same classpath container.

Tycho is despite its incubator status a good tool to test and build various Eclipse artifacts like plug-ins, features, target platforms, and products. Together with the above setup, we use Tycho on the CI servers to build, run tests and finally package p2 repositories for our plug-in projects.

More resources on that topic:

Upvotes: 3

Related Questions