Eclipse + TDD plugin?
How to do TDD when developing Eclipse plugins? Since PDE is a manifest based approach, there is no such thing as "test scope dependency".
Should I do another project on the maven based side? and adds the plugin project directly to the build path? (since the plugin project is not maven based, it won't be in .m2). It doesn't seem like a great setup ...
I read somewhere that a plugin snippet can do the job, but do I need to manually add Mockito or EasyMock to a custom repository? Or include it in the classpath inside that snippet? It doesn't look pretty portable.
I'm used to Bndtools , but is it suitable for eclipse plugins?
Also, I usually use Infinitest and MoreUnits , I guess the latter won't work if the tests are located in the second project?
Finally, I just read about Eclipse Tycho which is a collection of maven plugins for building eclipse plugins, would it be a good option even if it's in an incubator?
source to share
We have used test snippets on several projects for many years and found this to be the most practical approach.
Since the snippet uses the same classloader as its node, your tests can access internal packages and private parts as if there were no OSGi container.
Fragments can even have fragment.xml
where you can make additions for testing if needed.
The most annoying part of plugin test development is PDE tests . Once your testable code requires the desktop to be running, test execution is significantly reduced. PDE tests run the Eclipse workbench to run tests.
Therefore, we try to isolate our code from the Workbench code as much as possible. This allows us to write "quick" simple JUnit tests when possible, and only resort to PDE testing when absolutely necessary. Both tests can be in the same chunk and can be distinguished using a control pattern.
Test dependencies (JUnit libraries, Mock libraries, mate libraries, etc.) must be provided with the target framework (along with other non-test dependencies). While mixing these dependencies may seem strange, we have not had any problems with it in paractics.
MoreUnit fits perfectly into this setup. It can be configured (per project) to look for test / production code classes in specific source folders, even if they are in a different project.
Infinitest is probably not suitable for running PDE tests, simply because their execution speed is slow and Infinitests are often running fast tests. But if PDE tests can be excluded, you can still use it for simple JUnit tests.
In the example, the Eclipse Extras project applies the methods described - if you are interested, you can explore the sources to see how they work in practice.
If you're starting from scratch, Bndtools is definitely worth considering. I have heard that Bndtools developers use Bndtools to create Bndtools. AFAIK Bndtools doesn't support editing plugin artifacts like plugin.xml
. But perhaps you can use the PDE plugin editor along with Bndtools to edit extension and extension points.
In a typical Bndtools project, your production code and test code are in different source folders under the same project as the maven project. However, the source folder is test
not included in the resulting package.
The downside of having production and test code in the same project is that the test dependencies are visible from the production code. This is because both source folders share the same classpath container.
Tycho , despite its incubator status, is a good tool for testing and building various Eclipse artifacts such as plugins, features, target platforms, and products. Along with the above setup, we use Tycho on the CI servers to build, run tests, and finally a p2 repository package for our pluggable projects.
Additional resources on this topic:
source to share