2011-02-28

FreeFileSync : A free tool to synchronize folders

I recently wanted to synchronize few folders of a Windows machine.
I had some experience with DeltaCopy which is a front end to rsync (cygwin).
It was OK, but I had problems synchronizing some Cyrillic files, and honestly I don't think it is the easiest tool to use...

I wanted something simpler.

I ended up to play with FreeFileSync, an open source application hosted on SourceForge.
I was amazed by the quality of this tool. It is quite efficient and easy to use.

The interface is available in many languages, it is intuitive and has very interesting options. The help is very comprehensive. The tool is well polished and has professional features.

It supports larges files, it has a 64 bits version, it supports synchronization of a huge amount of files and it supports very deep paths. You can use it to backup folders on a network drive. You can mirror, update, and customize the way you want to synchronize folders. The synchronization operation is very fast. You can compare files using the combination of timestamp and size or by content. (I guess md5 is used to compare).  If you wish, you can save your sync configuration and use it later.


There are binaries available for Ubuntu 10.04, however I haven't tried this version yet.


It is a matter of minutes to get used to the tool and to get your job done.

If you need to synchronize folders in a few clicks, and you want a software that is easy to understand FreeFileSync is the tool you need!

Happy syncing! 

2011-02-03

Mockito Recipes

Last year I met a very interesting framework : Mockito.

Mockito is a mock framework for Java. It helps the developer to create mock objects for unit testing.  If you are new to mocking, I suggest you to read Martin Fowler's "Mocks Aren't Stubs".

There are many mock frameworks in Java. I tried JMock before, however I found that Mockito was easier to use. With JMock you must specify all the invocations that occurs on the mock object. If you don't do it, your test will fail. Mockito is more permissive in this way. With Mockito, if you really need to verify an invocation, you just specify it.

Of course, if you practice Test Driven Development, I think it’s better to use JMock’s style. But it’s good to know that you can use Mockito in the JMock’s way, by telling Mockito to verify all the invocations. For this reason, I think Mockito is a more versatile framework for mocking objects.

When you verify the interactions with a mock object, you make sure that it doesn’t make unplanned interactions with an unrelated object. There's an interesting post on the subject by J.B. Rainsberger on his blog.

However, I don't want to spark a debate on mocking techniques, the goal of this post is to get you started with Mockito.

So to start with Mockito :

Add JUnit’s and Mockito’s static imports. It helps the readability of the code.

import static org.junit.Assert.*;
import static org.mockito.Matchers.*;
import static org.mockito.Mockito.*;

Now you are ready to do some mocking!

Here are some Mockito recipes :

List<String> list = mock(List.class);

list.add("Test");
list.clear();

// verification
verify(list, times(1)).add("Test");
verify(list, times(1)).clear();

list.add("Test");
list.clear();
list.contains("Test");

//in order verification
InOrder inOrder = inOrder(list);
inOrder.verify(list).add("Test");
inOrder.verify(list).clear();
try {
// verify that there is no more interaction with the object
 verifyNoMoreInteractions(list);
 fail();
} catch (NoInteractionsWanted e) {
 // Expected
}

// thenThrow pattern
when(list.add(eq("Test"))).thenThrow(
  new RuntimeException("Major failure"));
try {
 list.add("Test");
 fail();
} catch (Exception e) {
 // Expected
}

// thenReturn pattern + chaining
when(list.contains(anyObject())).thenReturn(false).thenReturn(true);
assertFalse(list.contains("Test")); // first thenReturn
assertTrue(list.contains("Test")); // second thenReturn

// thenAnswer pattern
when(list.contains(any(String.class))).thenAnswer(
  new Answer<Boolean>() {
   @Override
   public Boolean answer(InvocationOnMock invocation_)
     throws Throwable {
    // do some stuff here (during the invocation,

    // you could play with the invocation parameters for
    // example)

    return ((String) invocation_.getArguments()[0])
      .startsWith("T");
   }
  });

assertTrue(list.contains("Test"));
assertFalse(list.contains("Best"));

// this boolean is used only for showing
// that the    code in the     answer object
// is really invocated
final AtomicBoolean invocated = new AtomicBoolean();

// mock of a void method call
doAnswer(new Answer<Object>() {
 @Override
 public Object answer(InvocationOnMock invocation_) throws
Throwable {
  // do something useful if it make sense :)
  invocated.set(true);
  return null;
 }
}).when(list).clear();

assertFalse(invocated.get());
list.clear();
// assert that the code in the Answer has been executed.
assertTrue(invocated.get());


// spy on an instance
// lets make a dummy class.
class TestSpy {
 private String _name;

 public void setName(String name_) {
  _name = name_;
 }

 public String getName() {
  return _name;
 }
}
;
// spy on it.
// (be sure to read the javadoc of the spy method prior using it)
TestSpy t = spy(new TestSpy());
t.setName("will");
assertEquals("will", t.getName());

// change the behavior of the getName() method
when(t.getName()).thenReturn("bob");
assertEquals("bob", t.getName());


Happy mocking!