Over a million developers have joined DZone.

Testing Formatting in Eclipse Editors

DZone's Guide to

Testing Formatting in Eclipse Editors

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

Starting with the next version of protobuf-dt, we are going to focus on a better editing experience, starting with a good code formatter.

Even though Xtext provides a nice infrastructure for implementing editor formatters, it is also important to test that the formatter is doing what I think it is doing. I wanted my tests to be reliable, short and readable. Well…who doesn’t? :)

I could write a unit test that verifies that I’m using Xtext’s infrastructure correctly. Unfortunately this approach is unreliable: the test may pass and my assumptions about the framework could still be wrong. Functional testing is the best approach I could think of.

Testing a formatter would involve creating a .proto file, inserting some text in the editor, triggering formatting and verifying that the text was formatted correctly. The best tool for this type of automation? SWTBot of course!

To write short and readable tests, I used the technique I described in the post “A simple way to test Eclipse-based editors,” with a few tweaks. Each of my test methods contain two comments with the same text. The first comment contains the text to insert in the editor while the second comment contains the formatted text. I access these comments through a JUnit rule.

Here is a example of a test method.

 // import "dummy.proto";import "google/protobuf/descriptor.proto";
  // import "dummy.proto";
  // import "google/protobuf/descriptor.proto";
  @Test public void should_format_normal_import() {
    SWTBotEclipseEditor editor = robot.createFile("formatNormalImport.proto");
    Comments comments = commentsAbove();
    assertThat(editor.getText(), equalTo(comments.expected));

What I like the most about this approach is the separation of test code and data (Protocol Buffer code.) The benefits are, IMHO:

  1. We reduce noise in test code by not having setup of test data (e.g. string concatenations, StringBuilders, etc.)
  2. We don’t have to escape characters in test data (e.g. double quotes,) improving its readability
  3. Copying/pasting text between tests and a real editor is as simple as selecting text, then pressing “Ctrl+C”, “Ctrl+V” and “Ctrl+/”

If you’d like to know more details about this test, please take a look at these classes:

  • Formatter_Test: the whole test class.
  • ProtobufBot: subclasses SWTWorkbenchBot and adds useful utilities (e.g. delete all projects in a workspace, create a file in a project, etc.)
  • CommentReaderRule: JUnit rule that reads the comments of test methods (using a CommentReader) and makes them accessible from test code.

Feedback is always welcome :)


Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}