In my previous post I described how I tested formatting in a Eclipse editor. The decision to write a functional test made sense back then because I didn’t know how formatting internally works but I knew what to expect from formatting, from the user’s perspective. In addition, I was itchy to try this cool tool, SWTBot :)

Luckily, Moritz Eysholdt, a Xtext committer, was kind enough to leave a comment in my previous post explaining how he unit-tests formatting in a Xtext-based editor (take a look at his great presentation: “Test-Driven Development of Xtext DSLs“.)

Moritz’s approach to unit testing is similar to mine in the sense that he separates test data from test code. The difference is that in his approach, test data is not in the test class itself, but in separate files. I personally prefer to have everything, test code and test data, in one place. Having test data as comments is, so far, my favorite way to separate it from test code.

Thanks to Moritz now I know that I can use INodeModelFormatter to unit-test formatting. My new formatting test looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class ProtobufFormatter_Test {
  @Rule public CommentReaderRule commentReader = overrideRuntimeModuleWith(unitTestModule());
 
  @Inject private INodeModelFormatter formatter;
 
  // import 'dummy.proto';import 'google/protobuf/descriptor.proto';
 
  // import 'dummy.proto';
  // import 'google/protobuf/descriptor.proto';
  @Test public void should_format_normal_import() {
    ICompositeNode rootNode = commentReader.rootNode();
    IFormattedRegion region = formatter.format(rootNode, 0, rootNode.getText().length());
    String formatted = region.getFormattedText();
    assertThat(formatted, equalTo(commentReader.expectedText()));
  }
}

The most interesting part in the code above is line 2. The JUnit rule CommentReaderRule is the one doing the heavy lifting:

1. Reads the comments in each test method
2. Parses the first comment (the text before formatting)
3. Makes the second comment (the formatted text) available via the method expectedText

Another interesting aspect of this testing approach is that each test method has exactly the same code, all the context is in the comments. After removing some duplication, my test class looks like this:

  // package com.google.proto.test;import 'google/protobuf/descriptor.proto';
 
  // package com.google.proto.test;
  //
  // import 'google/protobuf/descriptor.proto';
  @Test public void should_format_package() {
    assertThatFormattingWorksCorrectly();
  }
 
  // import 'dummy.proto';import 'google/protobuf/descriptor.proto';
 
  // import 'dummy.proto';
  // import 'google/protobuf/descriptor.proto';
  @Test public void should_format_normal_import() {
    assertThatFormattingWorksCorrectly();
  }
 
  private void assertThatFormattingWorksCorrectly() {
    ICompositeNode rootNode = commentReader.rootNode();
    IFormattedRegion region = formatter.format(rootNode, 0, rootNode.getText().length());
    String formatted = region.getFormattedText();
    assertThat(formatted, equalTo(commentReader.expectedText()));
  }

Now my tests run super fast (no UI and no OSGi) and are reliable. Sweet!

Note: This new approach works with Xtext-based editors only. The previous one did not rely on Xtext internals and could be used to test formatting on any Eclipse editor.

Feedback is always welcome :)

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();
    editor.setText(comments.beforeFormatting);
    formatAndSave(editor);
    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 :)

I’m very proud that my contribution, infrastructure for creating external-tool-based code checkers, is in the Eclipse CDT code repository!

Background

(Adapted from my EclipseCon Europe 2011 session)

Eclipse CDT 8.0, part of the Indigo release, includes a nice code checking framework: Codan. Out of the box, Codan provides both the infrastructure needed to perform code checks and some useful, ready-to-use checkers.

Even though the provided checkers are a great addition to a developer’s toolbox, many more are needed for Codan to have feature parity with existing tools like Cppcheck. In addition, Codan’s infrastructure provides good support for writing AST-based checkers, but support for integrating external tools was missing.

Why?

The main reason for integrating Codan with external tools is to enjoy all the code checks from mature tools without leaving our beloved Eclipse. With the new infrastructure:

• External tools can be configured using Codan’s preference page
• External tools are invoked automatically when a C/C++ file is saved
• The output of these tools can be displayed as editor markers

Example: Cppcheck

My contribution includes a Cppchecker-based checker. This checker is disabled by default but it can be easily enabled and configured in the Codan preference page.

A more detailed configuration dialog can be found by pressing the “Customize Selected…” button:

As you can see from the screenshot above, you can specify the path of the Cppcheck executable, the arguments to pass and whether Cppcheck’s output should be displayed in the console.

Now, let’s see it in action!

Writing your own external-tool-based checker

The new infrastructure makes it very easy to write your own external-tool-based checker. In the simplest case, you will need to:

1. Extend the abstract class AbstractCxxExternalToolBasedChecker.
2. Provide the name of your tool (e.g. “Cppcheck”.)
3. Provide default values for the path of the executable, arguments to pass and whether the output of the tool should be displayed in the console.
4. Provide one or more implementations of AbstractOutputParser. They will parse the output of the external tool, line by line. It’s up to you to decide what to do with the output (e.g. create error markers.)

You can take a look at the CppcheckChecker class here.

In the case of tools that are complex to set up, the new infrastructure is extremely flexible and configurable. It allows you to pretty much to configure every single aspect of the checker, from the files that the tool can check to the way to feed arguments to the tool.

Special thanks

Many, many thanks to my teammate and mentor, Sergey Prigogin, for his guidance and for reviewing and improving this work.

Sergey is one of the best engineers I have ever met in my career (in fact, he is in my top-3 list,) a nice gentleman, and the toughest code reviewer…ever. His attention to detail and his high standards for quality are just out of this world.

One of the most popular features of protobuf-dt is its integration with protoc, the Protocol Buffer compiler. When this feature is enabled, protobuf-dt invokes protoc to generate Java, C++ or Python code when a .proto file is saved.

A fairly common feature request is navigation from generated code to its declaration in the .proto file. For example, navigating from a generated C++ class that extends ::google::protobuf::Message to the actual declaration of the Message element in a .proto file.

I started working on this feature a week ago and now I’m happy to show off some progress. The following movie demonstrates the following:

1. How to enable and configure protobuf-dt’s integration with protoc
2. How C++ code gets generated after saving a .proto file
3. How to navigate from the generated code to the protocol buffer declaration

Under the covers

To accomplish this code navigation, I created an Eclipse plug-in that acts as a bridge between CDT and protobuf-dt. Navigation from generated C++ code to its declaration in a .proto file is as easy as right-clicking on a C++ element and selecting the menu “Open Declaration in .proto File.”

Under the covers, the bridge plug-in does the following:

1. Finds the C++ AST node enclosed in the current cursor position in the active CEditor
2. Derives the qualified name and type of the proto element from the qualified name and type of the C++ element found in the AST
3. Asks the Xtext index for the URI of the proto element that has an equal qualified name and type
4. Asks the Xtext index for the closest match, if the previous step failed
5. Asks Xtext to open and select the element under the found URI

Of course, this a over-simplified explanation. For more details, the source code of the bridge can be found here.

Challenges

Creating this plug-in was not too difficult. I think the biggest challenge is reverse-engineering protoc to figure out how navigation from generated C++ code to .proto files should be done. A good example is nested Protocol Buffer messages. When a nested message is compiled to C++, protoc creates a top-level class using underscores in the name to concatenate the names of its ancestors.

For example:

Both the messages Outer_Message.Inner and Outer.Message.Inner will generate a C++ class with name Outer_Message_Inner. In this case, there is no single path for navigating from C++ to Protocol Buffer. Currently we identify this ambiguity and select the first match only. I’m thinking about displaying a dialog showing all the possible options and let the user chose the Protocol Buffer element to navigate to.

Another thing I haven’t figured out is how to enable this menu only for files with names ending with “.pb.h.” Here is how I define the menu in the plug.xml file:

<extension point="org.eclipse.ui.popupMenus">
  <viewerContribution
      id="com.google.eclipse.protobuf.cdt.cEditorPopup"
      targetID="#CEditorContext">
    <action
        class="com.google.eclipse.protobuf.cdt.ProtobufCdtExecutableExtensionFactory:com.google.eclipse.protobuf.cdt.actions.OpenProtoDeclarationAction"
        icon="icons/pb.gif"
        id="com.google.eclipse.protobuf.cdt.openProtoDeclaration"
        label="Open Declaration in .proto File"
        menubarPath="group.open"
        style="push">
     </action>
   </viewerContribution>
</extension>

Any suggestions or hints are appreciated! :)

Road ahead

I only scratched the surface of what can be done to integrate C++ and Protocol Buffers in Eclipse. There are still a lot of things to do. In the case of C++-to-Protocol-Buffer navigation, I still need to:

• Figure out how protoc handles letter cases and C++ keywords in Protocol Buffer element names
• Implement message field matching by both qualified name and type (currently matching is done by qualified name only)
• Support navigation for the rest of Protocol Buffer elements: enum literals, groups, rpcs, services and streams

There is also other functionality that would be really useful to have:

• Cross-language refactoring: update all references in generated code when a Protocol Buffer element is renamed.
• Find usages of Protocol Buffer elements in generated code. This functionality can also have other interesting uses. Eclipse can warn a user, before deleting a .proto file, that there are dependencies on the code generated from that .proto file.

For now I’m concentrating on C++. Java support will come next.

Summary

In this post I have show you some of the upcoming functionality in protobuf-dt. Navigation from generated C++ code to its declaration in .proto files in Eclipse is a handy feature that is finally being implemented. It is not complete yet, but I expect to have a “beta” (or “testing”) release pretty soon.

Feedback is always welcome :)

In this post I’ll be using a brand-new Xtext project. To keep things simple, I’ll use the default file extension (mydsl) and grammar. You can get the source code of this post from Xtext Samples, a new open source project where I plan to store the code I use in Xtext-related posts. All code is released under the Eclipse Public License (EPL) 1.0.

The following steps assume we are going to associate our Xtext editor with the file name “MyDsl.”

1. Modify the plug-in’s XtextEditor to make it understand file names, instead of file extensions.
2. Create a ContentHandler that describes the content of files with name “MyDsl.” As part of this step we need to create a new content type for “MyDsl” files.
3. Create an IResourceServiceProvider that provides services (e.g. validation, content description, encoding) to files with name “MyDsl.”
4. Register the classes created in the previous steps, to make them visible to EMF and Xtext.

1. Modify the plug-in’s XtextEditor to make it understand file names

This is the easiest of all steps:

1. Open the file plugin.xml in the “ui” project.
2. Select the “plugin.xml” tab at the bottom of the editor, to edit the XML code directly.
3. In the editor element, replace extensions="mydsl" with filenames="MyDsl"

2. Create a ContentHandler that describes the content of files with name “MyDsl”

Here is a simplified version of our ContentHandler. You can find the complete file here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class MyDslContentHandler extends ContentHandlerImpl {
  public static final String MY_DSL_FILE_CONTENT_TYPE = "com.google.eclipse.MyDsl";
 
  @Override public boolean canHandle(URI uri) {
    return isMyDslFile(uri);
  }
 
  @Override public Map<String, Object> contentDescription(URI uri, InputStream inputStream,
      Map<?, ?> options, Map context) throws IOException {
    Map<String, Object> description = super.contentDescription(uri, inputStream, options, context);
    if (canHandle(uri)) {
      description.put(VALIDITY_PROPERTY, VALID);
      description.put(CONTENT_TYPE_PROPERTY, MY_DSL_FILE_CONTENT_TYPE);
    }
    return description;
  }
}

Line 2: We define a new content type for “MyDsl” files. We keep the constant public since we will be using it later.
Line 4: We specify that file names with name “MyDsl” can be handled by the ContentHandler. We call the utility method isMyDslFile(URI) from the class URIs.
Line 8: We declare the content of “MyDsl” files as valid and associate its type to the one defined in line 2.

3. Create an IResourceServiceProvider that provides services to files with name “MyDsl”

Here is a simplified version of our IResourceServiceProvider. You can find the complete file here.

public class MyDslResourceServiceProvider extends DefaultResourceServiceProvider {
  @Override public boolean canHandle(URI uri) {
    return isMyDslFile(uri);
  }
}

We call the utility method isMyDslFile(URI) from the class URIs to specify that this IResourceServiceProvider can handle files with names “MyDsl.”

4. Register the classes created in the previous steps, to make them visible to EMF and Xtext

Now it’s time to wire up everything together. First, we bind IResourceServiceProvider to our MyDslResourceServiceProvider in the plug-in runtime module:

  public Class<? extends IResourceServiceProvider> bindIResourceServiceProvider() {
    return MyDslResourceServiceProvider.class;
  }

Now we tell Xtext and EMF, in MyDslUiModule‘s constructor, to understand files named “MyDsl.”

public class MyDslUiModule extends AbstractMyDslUiModule {
 
  public MyDslUiModule(AbstractUIPlugin plugin) {
    super(plugin);
    configureXtextToWorkWithFileNames(new InjectorProvider());
  }
}

We pass an InjectorProvider that obtains the plugin’s Injector only at the moment when it is needed. At this point we cannot pass the Injector directly, since it has not been fully constructed when configureXtextToWorkWithFileNames is called.

The method configureXtextToWorkWithFileNames(InjectorProvider) is defined in XtextSetup:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

final class XtextSetup {
 
  static void configureXtextToWorkWithFileNames(InjectorProvider injectorProvider) {
    register(new MyDslContentHandler());
    register(new ResourceFactoryDescriptor(injectorProvider));
    register(new ResourceServiceProvider(injectorProvider));
  }
 
  private static void register(ContentHandler h) {
    ContentHandler.Registry registry = ContentHandler.Registry.INSTANCE;
    registry.put(HIGH_PRIORITY, h);
  }
 
  private static void register(Resource.Factory.Descriptor d) {
    Resource.Factory.Registry registry = Resource.Factory.Registry.INSTANCE;
    registry.getContentTypeToFactoryMap().put(MY_DSL_FILE_CONTENT_TYPE, d);
  }
 
  private static void register(Provider<IResourceServiceProvider> p) {
    IResourceServiceProvider.Registry registry = IResourceServiceProvider.Registry.INSTANCE;
    registry.getContentTypeToFactoryMap().put(MY_DSL_FILE_CONTENT_TYPE, p);
  }
}

Line 4: We register the ContentHandler we created in step 2.
Line 5: We associate the IResourceFactory in the plug-in’s Guice module with the content type defined in step 2.
Line 6: We associate the IResourceServiceProvider we created in step 3 (and later on registered in the plug-in’s Guice module) with the content type defined in step 2.

Testing the editor

To run the editor, right-click any of the projects and select “Run As” > “Eclipse Application” from the context menu.

Here is a screenshot of the editor opening a file named “MyDsl”

Summary

In this post I have shown how to make Xtext understand file names in four easy steps. You can find the code for this post in the project Xtext Samples. You can checkout the code, browse it or download it.

Even though I spent a good amount of time reading Xtext and EMF code to figure this out, I cannot claim my solution is the best one. Please let me know if you know a better way to do what I described in this post :)

Feedback is always welcome.

During this past weekend I upgraded protobuf-dt to the new and shiny Xtext 2.1.1. I didn’t have a real need for the upgrade, the protocol buffer editor has been working well with version 2.0. It was mostly curiosity.

Once again, the Xtext team did a great job. We, Xtext users, got an early Xmas gift. Soon after upgrading I was pleasantly surprised by some pretty good improvements. These are my favorite ones:

1. Removing grammar ambiguity is easier. The soon-to-be-released version 1.1 of the protocol buffer editor aims at supporting 100% of the language syntax and scoping rules. Unfortunately the grammar for the protocol buffer is ambiguous, and I was having a hard time cleaning it up (I’m still a Xtext newbie.) The syntactic predicates I added to remove ambiguity in the grammar did not work in 2.0, but they worked fine in 2.1!
2. Speed, speed, speed. My tests now execute considerably faster. Now I can run them constantly (even the integration tests,) without losing context. Note: I don’t have any numbers to back up this claim (I wasn’t even expecting any speed improvements.) I was just amazed to see how fast my test suite now runs.
3. Rename refactoring now works. In Xtext 2.0 I had a few use cases where rename refactoring did not work well. It is all fixed in Xtext 2.1.
4. Marker customization. Xtext comes with a really nice framework for adding semantic checks to your editor. Unfortunately, in Xtext 2.0 all editor markers created by this framework were of type “Xtext Check.” There was no way to change such type (e.g. “Protocol Buffer Problem.”) Now this is fixed in 2.1 (tracked as bug 351963.)

Please note that these are just my first impressions after upgrading, I’m sure there are more goodies in Xtext 2.1 :)

As a side note, one of my sessions proposals, “Xtext Success Story at Google,” got accepted for EclipseCon 2012 as an early-bird pick. I hope to see you there!

Verifying that scoping works correctly involves:

1. Specifying and parsing protocol buffer-content to use for testing
2. Find a specific element in the parsed file
3. Verify that scoping returns all the possible elements that can match the element found in step #2

An additional requirement is to make tests as lightweight as possible (e.g. do not require to instantiate a full Eclipse for running tests.)

1. Specifying and parsing protocol buffer-contents to use

My first attempt was to put all the protocol buffer code in a StringBuilder and then passed it to my XtextRule to get an AST back, as follows:

@Rule public XtextRule xtext = createWith(integrationTestSetup());
 
@Test public void should_provide_Property_fields_for_custom_field_option() {
  StringBuilder proto = new StringBuilder();
  proto.append("package com.google.proto;                   ")
       .append("import 'google/protobuf/descriptor.proto';  ")
       .append("                                            ")
       .append("extend google.protobuf.FieldOptions {       ")
       .append("  optional int32 code = 1000;               ")
       .append("  optional int32 info = 1001;               ")
       .append("}                                           ")
       .append("                                            ")
       .append("message Person {                            ") 
       .append("  optional boolean active = 1 [(code) = 68];")
       .append("}                                           ");
  Protobuf root = xtext.parseText(proto);
  // test implementation
}

Needless to say, writing and maintaining this is a real PITA. To make it readable I have to add extra whitespace to each line so the whole thing looks square. In addition, copy/paste code from the protocol buffer editor requires also adding append and quotes to each line, plus formatting. On top of that, it makes the test method too long.

An alternative approach was to have .proto files in the file system. I was not happy with this approach since anybody reading the code will need to go to two places to understand what the test is doing.

Finally, I found a better approach: specify the protocol buffer text as a comment!

I didn’t come up with this idea myself, I’m just borrowing it from CDT. After implementing a simpler, but similar approach, my test looks like this:

// package com.google.proto;
// import 'google/protobuf/descriptor.proto';
//  
// extend google.protobuf.FieldOptions {
//   optional int32 code = 1000;
//   optional int32 info = 1001;
// }
//  
// message Person {
//   optional boolean active = 1 [(code) = 68];
// }
@Test public void should_provide_Property_fields_for_custom_field_option() {
  Protobuf root = xtext.root();
  // test implementation
}

This is a big improvement! First of all, the test method ends up being shorter and easier to read. Second, it is easy to type something in the protocol buffer editor, copy it, and paste it above a test method. Then I just have to highlight it and press Ctrl+/ to have the text converted to a comment.

In this new scenario, my custom XtextRule does the following,:

1. extracts the comment of each test method and creates a method name > comment mapping
2. parses the comment of a test method and creates an AST just before executing the test method, not earlier
3. keeps a reference to the root node of the AST, to be used by the test method itself

It looks good, but what about imported .proto files?

When testing scoping, it is absolutely necessary to verify that imported types are included correctly.

I originally had .proto files to be imported in the file system and stored in Git, which is ugly for the reason I mentioned before.

To make things better, I borrowed another idea from CDT: specify the text and file name of the .proto file to be imported in comments, XtextRule will create the file in the file system just before executing a test method.

Here is an example:

// // Create file custom-options.proto
// 
// package com.google.proto;
//
// import "google/protobuf/descriptor.proto";
//
// extend google.protobuf.FileOptions {
//   optional int32 code = 1000;
//   optional int32 info = 1002;
// }  
 
// package com.google.proto;
//  
// import 'custom-options.proto';
//
// option (code) = 68;
@Test public void should_provide_imported_Property_fields_for_custom_option() {
  // test implementation
}

In the example above we have two comments for a test method. The first one tells my XtextRule to create a file named “custom-options.proto” before executing the test method. The second comment will be the one parsed and whose AST will be stored by the XtextRule (just like in the previous example.)

Neat, isn’t it? :)

2. Find a specific element in the parsed file

This step is necessary to ensure that scoping returns all the possible types that a given reference may be pointing to.

In this example:

// package com.google.proto;
// import 'google/protobuf/descriptor.proto';
//  
// extend google.protobuf.FieldOptions {
//   optional int32 code = 1000;
//   optional int32 info = 1001;
// }
//  
// message Person {
//   optional boolean active = 1 [(info) = 68];
// }
@Test public void should_provide_Property_fields_for_custom_field_option() {
}

my test is going to verify that scoping returns the field options code and info as potential matches for (code). To do so, I first need to find the proper AST element that (code) represents.

Let’s say I want to search for the custom field option info. My original approach would require the following:

1. Find all the elements in the AST of type CustomFieldOption
2. If any result is returned from #1, find the one whose name is “info”

Here is an example:

Protobuf root = xtext.root();
// statically imported from CustomFieldOptionFinder
CustomFieldOption option = findCustomFieldOption(name("info"), in(root));

This solution by itself is not too bad, and it works! Unfortunately it requires one specialized finder per type in the AST. For a relatively simple language like Protocol Buffers, it would require more than 10 finders, which is too much code to maintain just for testing.

Enter CDT with a better approach, which requires only one finder for all the types in the AST. This finder looks for elements this way:

1. Find the first element matching some text
2. Verify that the found element is of the the specified type and has the specified name

For example:

CustomFieldOption option = xtext.find("info", ")", CustomFieldOption.class);

To find the custom option “info” this finder will:

1. concatenates the Strings passed as arguments and find the first element that matches the text “info)”
2. verify that the found element is a CustomFieldOption and has name “info” (the first String argument only)

As you can see, this approach is the complete opposite of my original one.

Since only one finder is needed, I can have my XtextRule create it and pass the root of the AST to it. This way, I don’t have to pass it to the finder every time I perform a lookup.

3. Verifying that scoping returns the correct types

This is actually DSL-specific. My only recommendation here is, if you are using JUnit, write your own Hamcrest matchers to keep test code short and readable, and without duplication.

Putting it all together

Here is how one of my tests for protobuf-dt looks like:

// message Person {
//   optional Type type = 1 [ctype = STRING];
// }
@Test public void should_provide_Property_fields_for_native_field_option() {
  // We have an overloaded version of "find" that takes only one <code>String</code>, 
  // to be used when the text to find and the name to match are the same.
  NativeFieldOption option = xtext.find("ctype", NativeFieldOption.class);
  IScope scope = provider.scope_PropertyRef_property(option.getProperty(), reference);
  Collection<Property> fieldOptions = descriptor().optionsOfType(FIELD);
  assertThat(descriptionsIn(scope), containAll(fieldOptions));
}

Please feel free to click these links to find the code of:

• XtextRule
• ModelFinder
• or just get the project’s source code, as described here

Feedback is always welcome! :)

Future posts

There are a couple of useful things I have done with Xtext that I’d like to blog about in the near future:

• Adding spell checking to comments and strings
• Opening files outside an Eclipse workspace
• Making Xtext work with file names, instead of file extensions

Now it is a matter of finding the time and energy!

What matters to me is that I’m enjoying what I’m doing. Did I say “enjoying”? I love what I’m doing. I work on development tools, all Eclipse-based. This is what I asked to work on when I joined. For me, development tools is one of the most interesting domains in Software Engineering. I could go on and on explaining why, but let’s just say that I feel I’m developing for myself: I am part of the target audience of the software I write. I spend most of the time in Eclipse, and I like to build stuff that makes my experience better.

I was lucky enough to land in the Engineering Tools organization. My team is just great: super nice, talented and humble folks. Our job is to make Eclipse able to handle Google’s massive code base and to build support for Google-specific tools and languages. The following are the projects I’m currently working on:

• CDT integration with static code analysis tools (which BTW it is the topic for my talk at EclipseCon Europe 2011)
• protobuf-dt, an editor for Protocol Buffers (released as an open source project in August)
• support for our build language (described in our official blog)
• help organize “EclipseDay at Googleplex” with Ian Skerrett

I’ve also been visiting other Google offices (Zurich, New York, Seattle and Kirkland) co-presenting a tech talk. We gave this presentation the first time at Google’s headquarters. It was our Director that not only suggested us to take the tech talk outside of Mountain View, he actually encouraged us to do so. Needless to say, it was an awesome, mind-opener experience.

I will never forget how protobuf-dt became one of my main projects. It started as a toy I worked on for a few nights, on my own spare time (it was not even a 20% project.) I was so excited about the progress I made in such short period of time that I showed it to my Director during a 1:1.

His response was the following:

“Alex, this is great but I don’t want you to work on this at home anymore. When you are home, you enjoy your time with you family. From now on you work on this here, at the office.”

At the end of the conversation he added:

“I want you to work on what you like. I want you to be happy. When you are happy, you will be successful. Just let me know if there is anything I can do to help.”

I was completely shocked. I have never heard anything like that before. From that point on, I knew I was at the right place.

Probably you heard many stories about why working at Google is great. I just wanted to share mine :)

Among all the object-oriented design patterns, I think Singleton has the worst reputation. They have been called “evil,” “liars” and even “stupid,” and for good reasons:

• singletons are global access points, making client APIs hide their dependencies on them
• singletons make testing harder, mainly because they are hard to mock and inject

This is true, but only when Singletons are implemented and used in the “traditional” way:

1. Singletons cannot be extended (note that the class is final and the constructor is private)

   public final class MySingleton {
    
     private static final MySingleton INSTANCE = new MySingleton();
    
     public static MySingleton instance() {
       return INSTANCE;
     }
    
     private MySingleton() {}
    
     public void doSomething() {
       // something here
     }
   }

2. Singletons are called anywhere in your code

   public void someMethod() {
     MySingleton.instance().doSomething();
     // keep doing stuff
   }

Nothing is completely evil

Just like everything else, nothing is completely good or bad. I’ve been using Singletons in the next version of FEST-Assert in a way that avoids the problems mentioned earlier:

1. Do not make the Singleton final, making creation of mocks from a Singleton possible (BTW, Mockito can mock non-final classes with private constructors.)
2. Have the Singleton’s constructor package-protected. This is handy if your Singleton depends on other classes that need to be mocked during testing of the Singleton. This way, in your test, you can change the state of a new instance of the Singleton, without changing static state (that is, the state of the Singleton instance of a class.)
3. Inject Singletons just like any other dependency, completely avoiding the “global access point” problem.

Sounds good. Show me the code!

The following code is similar to what we have done in FEST, but a lot shorter and simpler. You can also take a look at the code in the github repository.

Here is the Singleton:

public class MySingleton {
 
  private static final MySingleton INSTANCE = new MySingleton();
 
  public static MySingleton instance() {
    return INSTANCE;
  }
 
  @VisibleForTesting MySingleton() {}
 
  public void doSomething() {
    // something here
  }
}

Currently, I’m doing manual dependency injection, because I consider the project to be pretty small and I’m trying to keep external dependencies to a minimum. Of course, you can (and probably should) use Google Guice :)

public class SomeClient {
 
  @VisibleForTesting final MySingleton mySingleton;
 
  public SomeClient() {
    this(MySingleton.instance());
  }
 
  @VisibleForTesting SomeClient(MySingleton mySingleton) {
    this.mySingleton = mySingleton;
  }
}

As you may guessed by now, the constructor SomeClient(MySingleton) is used in tests, passing a mock MySingleton (and of course I also test that the default constructor uses the Singleton instance.) Any non-test code just calls the default constructor SomeClient().

Conclusion

Despite the bad reputation that Singletons have, they can still be pretty useful. As long as Singletons are:

1. extensible
2. injected, and
3. do not have static mutable state (state by itself is not bad)

they are as good as any other tool.

]]> http://alexruiz.developerblogs.com/?feed=rss2&p=1832 9 http://alexruiz.developerblogs.com/?p=1837 http://alexruiz.developerblogs.com/?p=1837#comments Mon, 28 Feb 2011 22:52:33 +0000 Alex Ruiz http://alexruiz.developerblogs.com/?p=1837 We are proud to announce that FEST-Assert 1.4 is out!

FEST-Assert is an “assertThat” library that provides a fluent interface for writing assertions. Its main goal is to improve test code readability and make maintenance of tests easier.

Example:

int removed = employees.removeFired();
assertThat(removed).isZero();
 
List newEmployees = employees.hired(TODAY);
assertThat(newEmployees).hasSize(6)
                        .contains(frodo, sam);
 
String[] newHires = employees.newHiresNames();
assertThat(newHires).containsOnly("Gandalf", "Arwen", "Gimli"); 
 
assertThat(yoda).isInstanceOf(Jedi.class)
                .isEqualTo(foundJedi)
                .isNotEqualTo(foundSith);

One of the biggest changes in this release is the implementation of Ansgar’s "Self Types." By using this brilliant technique we ended up with a smaller, cleaner code base that is easier to maintain.

Here are some numbers, comparing this release with the previous one:

Release	Lines of code	Tests	Code coverage
1.3	3,132	3,707	98.7%
1.4	2,051	1,849	100%

Please note that 1.4 has more features than 1.3 and yet the code base is 35% smaller!

Release notes

Bug


• [FEST-378] - Newly added assertThat(Iterable<?> actual) eagerly calls iterator() and can throw an NPE
• [FEST-402] - onProperty is unable to access properties from Object class
• [FEST-414] - Impossible to use Fest Assert 1.3 with Ivy
• [FEST-415] - IteratorAssert should delay Iterator comsumption as much as possible
• [FEST-416] - NPE in MapAssert due to FEST-329

Improvement


• [FEST-105] - Add isEither, or isOneOf
• [FEST-413] - Implement Ansgar's Self Types
• [FEST-423] - User-friendly date and calendar formatting

New Feature


• [FEST-111] - Add support for regular expression matching to StringAssert
• [FEST-381] - collection onProperty() assert might give nicer exceptions
• [FEST-400] - Add generic assertions isIn / isNotIn

You can download the latest release here (file fest-assert-1.4.zip.) FEST-Assert requires Java SE 5.0 or later.

Here are some useful links:

• Home Page
• Documentation (wiki)
• Javadocs
• Issues
• Users' Group

Feedback is always appreciated :)

]]> http://alexruiz.developerblogs.com/?feed=rss2&p=1837 7