This Effective Mockito Post will be IDE specific again but related to the last post on Mockito’s spies. If you’ve read Part 3 you should now be familiar how to use them to “pseudo mock” statics. When writing code it often comes to a point where we want to debug using single step debugging. When using Mockito and especially when spies come into the game there is still something pretty annoying.

That is, when we want to debug our Object-Under-Test’s real method and the object is a spy. When we try to step into the object’s method we always land in internal Mockito code. After a little reading we can drill deeper but the next landing place is in java.lang.reflect code and so on. To be honest, this is really not the nicest way to debug code. What I want is that regardless of whether I use spies or not, when I step into an object’s method I land directly in this method. In the past my workaround was to set a breakpoint in the test at the method call and in the method itself. This enabled me to stop at the first point and resume the execution until it stops the second time in the method. But there is a much more elegant way. Let’s see how we can do this.

First of all, let’s take a look at an example. The code below shows a simple test from the last Effective Mockito post. The test uses a spy to “pseudo mock” a static method. We set a breakpoint in the line of the isPropertySet call and debug this method. Sadly when doing this we run into the effect described above.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectText {
 
  @Spy
  private MyObject objectUnderTest;
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    boolean isPropertySet = objectUnderTest.isPropertySet();
 
    assertFalse( isPropertySet );
  }
 
}

When using Eclipse there is a very simple way to avoid this called “Step Filtering”. We can add packages or classes to this Filterlist using the preferences. When filters are activated the classes will automatically be skipped during debugging. By setting a filter like the one in the screenshot below we can simply step over the Mockito and reflection code.

If you are not using Eclipse there is probably a similar way to achieve this with your IDE. It would be cool if you would share this tip with us in a comment. Meantime, I hope that Step Filtering is as helpful to you as it is for me.  Finally, I want to thank Fluffi and Frank for getting me to dive into this.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: debugging, eclipse, Mocking, Mockito, test driven, testing, tips

In the previous Effective Mockito post we saw how to use the @Mock Annotation to get a clean test. In this post I want to show you how to use Mockito’s spy mechanism to eliminate testing troubles with third party libraries.

Testing is one of the most important things in software development. I assume you agree with me because you decided to read this blog post .  It goes without saying that when we develop software we often rely on third party functionality. This does not affect our testing because we can mock objects from third party libraries thanks to Mockito. But there is one thing that always ruins my karma…

That is, static methods. And even worse, static methods that depend on runtime state. I know there are solutions like PowerMock to enable mocking statics, but I think there is a more elegant solution to avoid the troubles with statics -  without manipulating the bytecode and without adding another mocking library, as we would with PowerMock.

Let’s dive into an example to see how. First, take a look at our third party code. In this example I know that I will have to use a static method from the framework which exists in the class FancyFrameworkUtil. The only purpose of this code is to show you that I have to use it and that the third party library changes its return type magically at runtime as the comment says (this sort of thing happens way too often).

public class FancyFrameworkUtil {
 
  public static String getProperty() {
    return "some runtime property"; // this property changes at runtime ;)
  }
 
}

Let’s get to the code we want to write: a highly sophisticated type called MyObject . This type has only one method called isPropertySet which will become API (by this I mean the method will be added to a public interface). The method only checks to see if the value of the third party’s framework has a specific value and returns a boolean depending on the value.

public class MyObject {
 
  public boolean isPropertySet() {
    String property = FancyFrameworkUtil.getProperty();
    boolean result = true;
    if( property.equals( "some runtime property" ) ) {
      result = false;
    }
    return result;
  }
 
}

We now know that the framework method returns a value that can change at runtime but this does not mean we can’t write a test.

public class MyObjectTest {
 
  private MyObject objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = new MyObject();
  }
 
  @Test
  public void testIsPropertySet() {
    assertFalse( objectUnderTest.isPropertySet() );
  }
 
}

As you can see it’s a very straightforward test. But it’s not complete because we haven’t tested what happens when the framework’s property value changes. We can’t be sure if our MyObject#isPropertySet ever returns true. I’m sure you’ve had a similar problem in the past, too.

At this point we have a choice. Introduce another framework to mock the static framework method or do something like the following. First, we need to extract the call to the third party library in a separate method in our MyObject implementation. It’s important that we change the visibility of this method to package private. This is the price we have to pay. But I don’t think its a high price because this method will not become API and is only visible in the implementation’s package. By separating the interface and the implementation into different packages this really isn’t a problem.

public class MyObject {
 
  public boolean isPropertySet() {
    String property = getProperty();
    boolean result = true;
    if( property.equals( "some runtime property" ) ) {
      result = false;
    }
    return result;
  }
 
  String getProperty() {
    return FancyFrameworkUtil.getProperty();
  }
 
}

This is all we have to do to our implementation to enable the “pseudo mocking” of the FancyFrameworkUtil‘s method. Now comes the testing, and at this point we can use a spy. A spy is a real object with one or many mocked methods. Therefore we can spy on our objectUnderTest. In our case we want to mock the getProperty method that was added last. It can look like this.

public class MyObjectTest {
 
  private MyObject objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = spy( new MyObject() );
  }
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    assertFalse( objectUnderTest.isPropertySet() );
  }
 
  @Test
  public void testIsPropertySetWhenPropertyChanged() {
    doReturn( "foo" ).when( objectUnderTest ).getProperty();
 
    assertTrue( objectUnderTest.isPropertySet() );
  }
 
}

As you can see in the test methods, the spying in the setUp method enables us to change the return value of the framework’s method by introducing a delegation step. With this we can ensure that our method isPropertySet reacts to changes in the framework’s property.

I hope it’s now clear how to use a spy to mock static framework methods by using delegation steps. If you know alternative ways, please take a minute to share it with us in a comment. By the way, there is also an @Spy Annotation you can use. Have fun spying

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: junit, Mocking, Mockito, Software craftsmanship, test driven, testing, tips

As promised in the first part of the “Effective Mockito” blog series, I will concentrate on Mockito specifics in the followup posts. So, the main topic for Part 2 is Mockito’s @Mock Annotation.

When I write tests I try to follow an explicit pattern, called the build-operate-check pattern. This was described by Uncle Bob in his book “Clean Code” (Page 127, Chapter 9). The main idea behind this pattern is that you try to split your test method into three parts. The first part sets up the environment, the second executes the method you want to test and the third part verifies the expected. You can also apply this pattern with Mockito using the @Mock Annotation.

When writing tests we often reach a point where we need a second object to get an object under test to work. That’s where we can use mocks . The test code looks roughly like this:

public class SecondPartTest {
 
  @Test
  public void testSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
 
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
}

As you can see we created an object of the type Something. This object needs another object of the type Strategy in its constructor and I decided to use a mock for this. After this we execute the method we want to test which is called doSomething. The doSomething method should invoke the method doSomethingConcrete on the object we passed in the constructor. As you’ve probably noticed, it’s the strategy pattern. I chose this one because it’s a perfect fit for the use of mocks. In the last step of the test we verify that the method doSomethingConcrete was invoked. Nothing special here.

It looks like a nice and clean little test to me. But, in most cases we have more than one test method in a test class. When a new test method is added, it could look like this:

public class SecondPartTest {
 
  @Test
  public void testSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
 
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

At this point our nice and clean little test is no longer as nice or clean. By adding one test method we introduced two redundant lines of code, the object instantiation and the mocking. This is a sign that we need to use fields for both the objectUnderTest and the mock, and create them in the @Before method as in this snippet:

public class SecondPartTest {
 
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    strategy = mock( Strategy.class );
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

This makes our test methods clean again, yippee . But I think we can do better. Mockito provides MockitoAnnotations and I’d like to use one of them in our test. It’s called @Mock (surprise).  Using this annotation we can tell a field that it is a mock.  It can look like this:

public class SecondPartTest {
 
  @Mock
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    MockitoAnnotations.initMocks( this );
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

This has at least one major benefit. You can see that a field is a mock at first glance without reading the setUp method. However, we didn’t save any lines in the setUp method because we need to tell Mockito to instantiate the @Mock annotated fields. This looks really ugly because we are mixing Mockito framework code with our test code. We need to find another way to instantiate the mocks. Luckily, Mockito helps out once again.

Since JUnit4 you can choose specific test runners for test classes. You probably know this because you use it in your TestSuite classes all the time. Anyway, Mockito provides a runner called MockitoJUnitRunner. Using the runner looks like this:

@RunWith( MockitoJUnitRunner.class )
public class SecondPartTest {
 
  @Mock
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

As you can see we could remove the initMocks call in the setUp method and we are nice and clean again. And, that’s how you can get to a clean test using the @Mock annotation. In the next Effective Mockito installment I’ll show you how spies can be used to get to a clean test when you depend on third party libraries .

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: clean code, Mocking, Mockito, Software craftsmanship, test driven, tips

Last week I talked to a fellow developer, Frank Appel, about Mockito. We’ve been using this mocking library for over a year. We both agreed that of all the innovations we’ve tried in the last year or so, Mockito has boosted our coding productivity the most. With this blog series we want to share our experiences with Mockito. You see that I used the word “effective” in the title, and, in this context I want to define “effective” as arriving at clean test and production code as fast as possible.

To understand these posts you need to have a basic understanding of what mocking is. I recommend reading Martin Fowlers article,”Mocks aren’t Stubs“. You’ll also need some practice with Mockito. But, since you found this blog, you probably searched for the term Mockito , so this should be a given. Anyway, there is a third thing, that only affects this first post. You need to use Eclipse as your IDE. This post shows you how to setup Mockito in your IDE for the daily work. If you are using another IDE and you know how to achieve what I have described here, please share your tips in a comment. The follow up posts will not require Eclipse because they will be more Mockito specific. Enough prerequisites, let’s start with with the first thing that will boost your Mockito experience.

I always write tests first. My goal is to come up with a first test method really quickly to be able to create all the classes that I need by resolving the compiler errors using Eclipse’s quick fix functionality (CTRL/CMD+1 is your friend). What would be ideal, is to create a test class and just write the test without importing all the other stuff.  The Mockito and Junit stuff should automatically appear in my content assist. When using Mockito, I want to create a test method, write “mo”, open the content assist and it should show me all the “mock” methods.

I’ll give you an example to make this clearer and to show how to achieve this. If I write a test method and open the content assist (which I use all the time), the standard selection options are very basic.

As you can see there are no “mock” methods but at least the Mockito classes. The reason is that the content assist only shows methods that are imported in the current class. So, by static importing Mockito this can be fixed.

But this is not what I want. This assumes that I have to import all Mockito stuff manually, or that I need to write “Mockito” and organize my imports automatically. I really want to be able to just write “mo” and get a pre-filled content assist. Luckily there is an option that lets us achieve this. In Eclpse it’s called “content assist favorites”. It can be configured within your preferences. Let’s take a look at our favorites.

As you can see, I added Mockito.*, Matchers.* and Assert.* to my favorites. This enables my content assist to show the available methods and import them when I’m using one. You may think, “hey, this will fill my content assist with unnecessary stuff when I’m writing production code.” But this is not the case. These imports are only available when Mockito and JUnit is on your build class path. So, by separating test and production code you only have these imports available in your test projects. Let’s take a look at the result.

As you can see I haven’t imported any Mockito stuff yet but I can select all the mock methods from my content assist. This enables me to write tests really quickly because I don’t have to think about setting up a test, I can just write it.

This is just a simple trick to come up to speed as quickly as possible when writing tests using Mockito. In the next posts I will focus more on the Mockito specifics. I hope you liked it and will stay tuned

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: Java, Mocking, Mockito, Open Source, TDD, tips

A few weeks ago the news in Germany was that the average lifespan of German citizens has reached its highest level ever (Statistisches Bundesamt Deutschland).  This was good news but I was also surprised to hear that women still live longer than men. I can imagine a lot of contributing factors but maybe that’s a long discussion better done over beers. One thing that I’ve observed, that I think I can say without getting into trouble, is that some women I know, are simply smarter about their health. For example, if they develop symptoms, they’ll go more quickly to the doctor than I would (or other guys I know). Longevity led me to think about the lifetime of code, and how short that can be sometimes. And, how we often ignore symptoms of illness in code too.  This would be in the form of warnings during compile time, like in the following example, “death by internal API change”.

With the right compiler settings, a modern IDE like Eclipse displays warnings when something isn’t right e.g. when using internal API.  By ignoring these warnings you are vulnerable to the ‘death by internal API change’ malady.  One day the owner of the API will change its internal structure. If you’re lucky you can adopt the new structure and your code will survive. But if you’re out of luck, the changes to the internal API are so drastic that you can’t repair your code and your application, built on top of internal API, is completely broken.

This death can be avoided by reacting to the symptoms. Let me explain this with the same example. Every programmer has found himself in the situation were a public API couldn’t do everything you needed.  If you’re writing code in a women’s way, you won’t ignore the symptoms.  A female would consult a doctor, in this case the creator of the API or the community around it. They would describe the symptoms, and with this kind of information the “doctor” can react by extending the public API of the framework. In this way, all symptoms (warnings) are recognized early and eliminated before the malady can take hold. It’s the same here as with people: if you consult the doctor early, the probability of illness will shrink.  So, be nice to your code…

Can you think of other examples where bad code is so easy to ‘catch’?  It would be great to hear your examples of  maladies like “death by internal API change” and hear your experiences.

Tags: api, clean code, programming, software, software engineering, tips

I know Eclipse ‘Help’ is not a very exciting topic, but today I found myself working with a little known secret of Help.  Most people know that you can setup context sensitive help (Press F1 and bring up help for the specific workbench part under focus).   However, did you now you do the opposite?  That is, activate code in your RCP application from a link in Help?

Here’s the use case:  Say you have created a chat client built on the Eclipse RCP Platform.  Like any good software engineer, you’ve created extensive help content.  In addition to Instructions, you want to provide links that actually open the dialogs, or perform the actions. Active Help is the solution.

In this example, I’ve added a link that opens the “Add Contact” dialog, directly from the “Adding a Contact” Help page.

Doing this is extremely simple too. On the Java side, you simply need to implement the ILiveHelpAction.  Then, on the help side you simply add the following JavaScript to your help contents:

<a href='javascript:liveAction(
	"org.eclipsercp.hyperbola",
	"org.eclipsercp.hyperbola.ActiveHelpOpenDialogAction",
	"")'>Click here for a Message.</a>

The only thing to keep in mind is that the Action is not executed on the UI thread, so you may need to synchronize this yourself.

Tags: tips

Here is a question that I got on a post about detached views:

“How can I detect that a View has been detached from the main window? I would like to adjust the view’s behavior in that case.”

There is no API to obtain that information directly. However it is possible to do this with a few tricks:

1. detached views have an empty window title (i.e. shell.getText().length() == 0)
2. when a view is detached resize events are fired

Armed with that knowledge we can detect that a view is detached / reattached. The snippet below shows how (tested on windows).

PS: Our eclipse support helps developers use their time efficiently by providing prompt answers to questions like this one.

Tags: detached views, eclipse ui, tips

From time to time, I’m in the situation when I want to suggest a UI change or even try to come up with a completely new UI. While I love programming, it may be easier in these situations to just “sketch” the idea instead of really getting your feet wet. As many people asked me what I use for UI sketches, I thought I should share it with you – the tool is called WireframeSketcher. It’s “just” an Eclipse plugin to create sketches pretty easily. As most of the UIs in my life are SWT-based, WireframeSketcher comes with one absolutely cool feature – turn an existing dialog into a sketch. Fire up any dialog, hit the magic “Alt+Shift+F5″ and you’re done. Is it that easy? Yes – I really love it. Here is an example of the Import Wizard which I also used in my latest blog post to further modify it with my ideas.

Not only is it easy to operate, it also has pretty good Eclipse integration and you always find the things where you expect them (eg. select and button and you can modify everything in the Properties View).

As Eclipse commiter, you can get a free licence of the plugin or you can buy the plugin from the author if you want to use it commercially. Either way, give it a try the next time you want to mock a new UI prototype.

Tags: eclipse, eclipse ui, sketch, swt, tips, ui, wireframesketcher

Here’s a nice addition to Riena’s TableRidget: you can now mark a table-row as incorrect.

This is done with an RowErrorMessageMarker. When hovering over the marked row, the corresponding error message will be shown in a tooltip.

IMarker marker = new RowErrorMessageMarker("An error message...", zorro);
tableRidget.addMarker(marker);
// to remove:
tableRidget.removeMarker(marker);

Full snippet here. This is shipping with the upcoming Riena 2.0 M6.

Tags: eclipse ui, riena, swt, tips

“Can you help me use shared libraries with Eclipse CDT, managed make and cygwin?“, I was asked yesterday. Read on for a list of common pitfalls and detailed instructions.

The instructions are based on the latest CDT release (Galileo) and cygwin (make 3.81, gcc 3.4.4). They are applicable to CDT’s managed make projects (that means CDT generates a makefile to build project).

The Pitfalls

It turns out that using a shared library on Windows is not as straight forward as you think. There are several pitfalls waiting for the unaware to fall into:

1. Recent versions of cygwin’s make insist on cygwin-style paths instead of windows paths (/cygdrive/c/foo instead of c:\foo). CDT is not picky about this and will generate an incorrect makefile, if you use workspace relative paths:

make all
example.d:1: *** multiple target patterns.  Stop.

The solution is to use absolute cygwin paths, such as: /cygdrive/c/workspace/mymath

2. The compiler and linker will not find the header files / library unless you set the appropriate parameters. The compiler needs an include path (-I). The linker needs the library name (-l) and library search path (-L). These settings are scattered in two places in the project properties. Their location is not obvious for a first-time user (details below).

3. When launching, Windows will not find the shared library (.dll) and greet you with the error pictured below. Unix users might try to set the LD_LIBRARY_PATH, which has no effect on Windows. The solution is to append the directory containing the .dll to the PATH (MSDN Article). Restart Eclipse for the changed PATH to take effect.

The remainder of the post walks you through the process of creating and using a simple shared library with cygwin and CDT.

Creating a Shared Library with CDT

Follow these instructions to create a shared library project with CDT.

1. File > New > Project > C Project > Next. Project name: mymath. Ensure “use default location” is checked. Note the location: c:\workspace\mymath — we’ll need it later. Project type: Shared Library; Empty Project. Hit Finish.

2. Create a header file (mymath.h) and the corresponding implementation (mymath.c). The example below provides a trivial function that multiplies two integers:

3. Afterwards save and hit Ctrl+B (or Project > Build All) to build the library. If cygwin is on your path, you should see a “Release” folder in your project containing the file “mymath.dll”.

4. For windows to find the shared library, you need to add the directory containing the .dll to your path. On Vista this can be done via: Control Panel > User Accounts > User Accounts > Change my environment variables.

5. Exit and restart Eclipse after changing the PATH. Otherwise the changes will not be picked up.

Using a Shared Library with CDT

Follow these instructions to use a shared library in a “managed make” CDT project.

1. File > New > Project > C Project > Next. Project name: example. Project type: Executable; Empty Project. Hit Finish.

2. In that project create a file named example.c with the following content:

3. Save and hit Ctrl+B to build the project. The second line will have an error: “mymath.h: No such file or directory”. We now have to adjust the compiler and linker settings so that the mymath.h / mymath.dll files are found during the build.

4. Select the “example” folder in the Project Explorer. Select “Project > Properties” from the menu. A dialog comes up. In the tree on the left open: “C/C++ General > Paths and Symbols”. In the “Languages” list, pick “GNU C”. Then hit “Add”. Enter the cygwin-style path to the “mymath” project: /cygdrive/c/workspace/mymath

Caution: When entering the path, don’t use the “Workspace” or “File system” buttons because the resulting path will not be compatible with cygwin’s make.

5. In the same dialog select: C/C++ Build > Settings in the tree on the left. In the “Tool Settings” tab find: “Cygwin C Linker > Libraries”. Hit the “+” icon in the “Libraries” section and add the name of the library: mymath

Caution: if your shared library starts with lib, omit the ‘lib’ prefix (i.e. libfoo becomes foo)

Hit the “+” icon in the “Library search path” section and add the path to the folder containing the shared library: /cygdrive/c/workspace/mymath/Debug

Hit OK.

6. You will be asked to rebuild the project. Answer “Yes”, but for some reason this will not rebuild your project. Hit Ctrl+B to rebuild. The error will go away.

Note: ignore the “unresolved inclusion” warning. It seems that CDT has trouble resolving cygwin-style paths. The generated make-file however will work as expected.

7. Select “example” in the Project Explorer. Right-click > Run As > Local C/C++ Application. At this point you see the result of the multiplication on the console. That means that the shared library was found and used successfully:

Kind regards,
Elias.

Tags: cdt, cygwin, tips, windows