Testing Eclipse RCP and Plug-in Applications

This blog post tackles the question "What is a must-have reading for a plug-in or RCP-apps developer when it comes to testing?"

Over the past couple of month, I collected more than 100 resources on testing Eclipse plug-ins and RCP applications. Today I want to share the 6 primary testing pointers, and summarize some of the most often stated recommendations on testing. This is a subjective collection, please feel free to add missing pointers in the comment section. On purpose, I spared links to specific utility tools or testing frameworks.

The main article and also starting point for further reading is the wiki entry on Automated Testing [1]. This article covers some basic information on how to run tests, suggests useful test utility frameworks and also presents a list of user interface (UI) test tools.
Another somewhat older article focuses on automating Eclipse PDE unit tests using Ant, and gives further pointers to articles about how to automate PDE tests [2].

From several documents on the web, as well as talks in Eclipse events like Eclipse Summit and EclipseCon, it is apparent that writing unit tests and having continuous integration/testing are recommended as a best practice for Eclipse development. As for example, the Architecture Council lists unit testing, and continuous integration under the top 10 project development practices [3].


Further Test Driven Development is one of the most discussed and recommended strategies when it comes to testing. There are several resources out there, I selected a TDD webinar by Kevin Taylor [4]. In his webinar he suggests to use the Model-View-Presenter pattern to separate concerns and thus the UI code from the logic behind, which in turn helps to reduce the code within the UI.

In addition I would like to include some pointers to books: First, the Eclipse specific book of Erich Gamma and Kent Beck “Contributing to Eclipse” [5], which explains how to contribute to Eclipse in a test driven way. Further, one very well known but general book on testing, by Binder, namely “Testing object-oriented systems: models, patterns, and tools”, provides several patterns that are handy for practical use [6].

What else has to be included in every Eclipse plug-in/RCP developer's reading list?
Missing something? Please leave a comment.

------------------------------------------ Edit:
I am happy that people responded to the post and extended my list of testing pointers.
Here the additional links from the comments:

"Agile Java(TM): Crafting Code with Test-Driven Development" by Jeff Langr.
"Effective Java" by Joshua Bloch.
"FAQ: How to build a product": http://wiki.eclipse.org/FAQ_How_do_I_create_an_Eclipse_product%3F
"Eclipse PDE Build - Tutorial": http://www.vogella.de/articles/EclipsePDEBuild/article.html
------------------------------------------

References:
[1]: http://wiki.eclipse.org/Automated_Testing
[2]: http://www.eclipse.org/articles/article.php?file=Article-PDEJUnitAntAutomation/index.html
[3]: http://wiki.eclipse.org/Architecture_Council/Top_Ten_Project_Development_Practices
[4]: http://live.eclipse.org/node/700
[5]: http://portal.acm.org/citation.cfm?id=961854
[6]: http://portal.acm.org/citation.cfm?id=338330

-------------------------------------------------------------

#1 Testing Proposition: Our Opinion Counts

This is the first of a series of posts aiming at sharing some thoughts on testing with you that are inspired by the interviews during the Eclipse testing study. I formulate the thoughts as statements allowing you to express your opinion. Do you agree/disagree? Have you experienced otherwise? Please feel free to use also the comments to express your opinion in some more words and to foster a discussion on this topic.

These statements must not express opinions and experiences from individual participants.

The first proposition is concerned with the point in time when testing should take place and stands in contrast to test driven development that propagates a test first approach. The proposition is concerned with the overhead caused by writing test code very early in the development phase.

Questions raised are: “Does focusing too much on testing immature components hinder further code development because the tests will need to be changed whenever the component is refactored or adjusted? Therefore, should test code evolve over time and with the maturity of the component under test? Or should be writing test code the first priority when developing new functionality?”

Now it's your turn. Do you agree or disagree with the following proposition?

Since young components are likely to change, early testing is counter-productive.