Posts Tagged ‘testing’

Help! I Programmatically Created a Resource in my Project, but My Code Doesn’t Find It!

January 1, 2011 5 comments

Let’s say that you wanted to test the existence of a file you programmatically created in your project. While there are a lot of situations where you might create an IResource on the fly, creating a file for use in a test is not a bad example.

The test code could look like this (TestUtilities is a convenience class that does things for me):

import org.junit.Assert;
    public void testFileExistsTrue() throws IOException, CoreException {
        _project = TestUtilities.createProject("x"); //$NON-NLS-1$
        TestUtilities.createTemplateFileInProjectAt(_project, CustomSchemaSupport.SCHEMA_FOLDER_NAME, CustomSchemaSupport.FILENAME);

        boolean actual = _customSchemaSupport.fileExists(_project);

        try {
        } finally {
            // always do this before returning
            _project.delete(true, null);

Read more…


Writing an Eclipse Plug-in (Part 23): Common Navigator: Rewriting History

August 14, 2010 3 comments

[I am now using Git for my source control using the EGit plug-in. Of course it is only partially working. One of my projects has fully committed and the others say they are in staging no matter how many times I tell EGit to Commit. Sigh.

Also, starting with this post I am also going to make the code in this convoluted journey available for download in each post as well as the Missing Zip Files page. It will always be available in the format of whatever Eclipse I happen to be using at the time (7/18/10: Eclipse 3.6 Helios Release) so don’t blame me if you are using an older version and something doesn’t work the way I describe it. If you follow me you walk the edge. Of course, in switching to EGit I have no idea where the code for Parts 21 and 22 have gone. I hate when that happens.

Don’t forget to add your favorite plug-ins: in my case that means EGit, EclEmma, Eclipse-CS, and UMLet]

[Woo hoo! Eclipse 3.6 is finally released! I can’t wait to be one of the first to download it! Hey! Where is everybody? Oh, it was released June 23? Really? I hate when I miss an opening party…by almost two months…but it was because I was busy…in Miami…meeting with Michael Westin…]

Well, long time no hear! Yes, I am trying to write these posts a little more often than I have been, but it is amazing how real life gets in the way…what with the cat coming in and out of the box and the squirrels distracting me to no end (don’t get me started on the platypus). I guess I may be stuck with only one post per month (maybe less).

I promise not to beat myself up over it.

Speaking of which: when I started this post the sun was out scorching everything, and I was doing everything I could to stay out of its path. After a failed attempt at getting back into running (you know, diet and exercise will help you live forever, unless you exercise wrong thereby screwing up your leg muscles making it almost impossible to walk), but after a successful attempt to eat better (salad and seafood, anyone?) it is time to pay attention to the things that keep us getting up in the morning and make life worth living (no, not sex, drugs, and rock and roll, though they help): Eclipse plug-ins.

I was going to write a post on genetic programming, but I suspect the cat hid my Koza book because it thought I was going to write a fitness function to force it to choose one state or another. I’ll do that on my next visit to Copenhagen.

What I will post about is, well, fixing the past. Usually, that is quite difficult, but we will make an exception and pretend that we can fix what we did, not because it was wrong, but because our needs have changed (that’s my story and I’m sticking to it).
Read more…

Writing an Eclipse Plug-in (Part 1)- What I’m going to do

July 8, 2009 6 comments

(The next few posts are a cheat. I have been slowly amassing these blogs for the last few weeks/months.)

So you want to write an Eclipse plug-in and don’t know where to start? Join the crowd. I wrote a great book on Eclipse (well, at least I liked it) and still find myself at a loss when it comes to implementing a standard feature set of functionality within a plug-in (sample chapters here).

I am going to document (read: heavily edit) what I did to implement a plug-in I am building to relearn all the things I wrote about in my book, but never really got a chance to use in this ever changing economy.

This blog will act as my requirements document as well as my FAQ. This way, when I forget how I did something I can just come here.

Where to Start?

Let’s say I have a software tool that is in desperate need of an IDE to help automate a number of silly tasks. That means a few things:

  • I want to aggregate the tasks
  • I want to aggregate any files involved in configuring the tool
  • I want to aggregate any source code involved in extending the tool

In addition, I want to use Mylyn to help me keep track of my tasks.

The list of things that can be done in Eclipse can be rather daunting. At a high-level this plug-in needs to accomplish a stardard list of things:

  • Create a project
  • Create some custom format XML files
  • Manage files within the project
  • Edit some XML files using a form-based approach rather than just editing the XML directly
  • Deploy files to a target directory

When it comes to adding functionality the best place to start is with use cases. Here are the ones I used:

  • Create a custom project
  • Edit a custom XML file
  • Deploy the files
  • Monitor how the deployed files have affected

The actor for all of the use cases will be a developer.

Create a custom project

The steps to create the custom project will be:

  1. Open the New Wizard dialog.
  2. Open the Custom Project folder
  3. Select the Custom Project item
  4. Press Next
  5. Enter the name of the project and a location in which to put it
  6. Press Finish
  7. A custom perspective will open

The custom perspective that will only display projects of my type. The project will contain custom categories where files will be displayed. The physical location of the files and the displayed location of the files in the navigator will be different. For example, the files may be located in:


The custom navigator will display the files in an almost flat structure:
My Project
  Category 1
  Category 2
  Category 3

If the user wants to see the actual folder structure they can look at the project in the Navigator view.

The custom perspective will display:

  • A custom navigator
  • The Navigator view
  • The Outline view
  • A log file view
  • Some yet-to-be-announced views
  • Editors as appropriate

The custom navigator will display individual images next to the workspace, project, categories and various file types that are displayed.

The custom navigator will allow the standard Eclipse behaviors from a popup:

  • Cut/copy/paste
  • Rename
  • Refresh
  • Workspaces
  • New
  • Project
  • Other

Edit a Custom XML file

There are a few XML files that need to be edited in a consistent and reliable way. The user will interact with a custom editor that will let them modify the XML file through a form or as XML text. The editor will have multiple form pages and one text page for direct XML editing.

Deploy the files

Once the files are in place, copy the files to the proper locations in the target software.

Right-click on the workspace or project will deploy the entire project.
Right-click on a particular category will deploy only the contents of that category
Right-click on a particular file will deploy just that file

In Addition

The above is all well and good, but the plug-in should also adhere to best practices whenever possible and that includes testing, putting strings in separate property files and flagging other strings as ignorable, caching images and disposing them.

What about testing? Testing is certainly interesting in the development of an Eclipse plug-in. The Eclipse Plug-ins book explains how to test a plug-ins, but there are a few things to bear in mind when testing anything:

  • Don’t test the platform
  • Test new functionality
  • Test before fixing a bug

I don’t enjoy having to change the API of a class to support testing, but sometimes there aren’t a lot of ways to test an API without retrofitting Eclipse to support dependency injection.

Therefore I will not be writing tests when creating Wizards or perspectives, but I will be writing tests on the behavior that the various GUI components will execute when they are told to do something. For example, the GUI flow for the use case Create A Custom Project will consist of:

  • Opening the New Wizard dialog
  • Displaying one or more Wizard pages
  • Clicking Finish causes the custom perspective to open
  • Clicking Cancel leaves everything the way it was

The flow, as a first phase of implementation, can work with little or no code. Whatever code needs to be written will just be glue code. Once those pieces come together then behavior can be written:

  • Create a custom project
  • Display the custom project in a custom navigator

Bear in mind that the Eclipse Plug-in Wizard has a number of templates that you can select from to create most of what you need to implement the first phase of a plug-in. The problem is that some of the things I needed were not there so I thought it better to assemble it piece by piece and blog about it.

Sorry for all the talking and not implementing anything. And BTW, I might never finish. Hope that is not a problem.