Over a million developers have joined DZone.

Testing Formatting in Eclipse Editors

· Java Zone

Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems, brought to you in partnership with AppDynamics.

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 :)


The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.


Published at DZone with permission of Alex Ruiz , DZone MVB .

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}