>Testing Content Assistance Proposals Refactored

>In a follow up to the Testing Content Assistance Proposals article, Nitin found a couple of things I needed to tweak for working more efficiently with the Structured Source Editor and the Structured Document models.

Use getModelForEdit(file) instead of getNewModelForEdit(file, true):

protected IStructuredModel model;
protected IStructuredDocument document = null;

protected void loadXSLFile() throws ResourceAlreadyExists, ResourceInUse,
IOException, CoreException {
IModelManager modelManager = StructuredModelManager.getModelManager();
model = modelManager.getModelForEdit(file);
document = model.getStructuredDocument();

The difference here is how many reference counts are kept around for the model. Since we are only concerned about loading it and disregarding it, there isn’t a need to get basically a copy of the model to work with, when we can get just one instance of the model. Also, in the prior iteration the model variable was local, and it was refactored to a field. This will be explained next.

Release the Model When Done:

The model really should be released after you are done using it. The reason as I understand it is so that the cache that keeps track of the models can free the memory, and not have it hang around needlessly. To do this one calls the releaseFromEdit() method on the model that was loaded. The simpliest way to get the model that was used was to just make it a field and use it after it was loaded. This way it could be easily released later.

Updated 2009-01-19 to remove extra releaseFromEdit() in the catch.

public void testProposalsIncludeXHTML() throws Exception {
fileName = "TestXPathXMLProposals.xsl";
String xslFilePath = projectName + File.separator + fileName;


int offset = 251;

try {

ICompletionProposal[] proposals = getProposals(offset);
assertNotNull("Did not find proposals.", proposals);

for (int i = 0; i < proposals.length; i++) {
if (proposals[i].getDisplayString().contains("xhtml:")) {
} catch (Exception ex) {
throw ex;
} finally {

sourceViewer = null;
fail("Did not find XHTML proposals.");

The code is now surrounded with a try/catch/finally clause. The exception that is tossed by the assertion or another piece of code is caught, the model is released, and the exception is rethrown so that Junit can handle it properly. Otherwise if we complete everything correctly or we get a valid result, we hit the finally clause before leaving and release the model. This can potentially save some issues with out of memory and heap space allocation issues in the future.

While I was in this code, I also took the time to refactor the tests themselves. I noticed I had several duplicate methods doing the exact same work in multiple classes. So these have now been refactored into an AbstractCompletionProposalTest class, which all of the other Completion Proposal classes extend. AbstractCompletionProposal itself extends the AbstractXSLUITest class so that it inherits the necessary project setup information.

So thanks, to Nitin, the code is now much better behaved, and it is cleaner too.

This entry was posted in eclipse, refactoring, testing. Bookmark the permalink.

2 Responses to >Testing Content Assistance Proposals Refactored

  1. Djo says:

    >Hi :), Correct me if I am wrong, but in the try/catch/finally you show, if an exception is thrown, releaseFromEdit will be called 2 times : finally is always called, wether an exception was thrown or not.

  2. David Carver says:

    >@Djo: Yes, you are correct and it’s my mistake. Here is what the specification for try,catch,finally says.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s