Convert time to EST

Code to convert given time in UTC milliseconds to EST, irrespective of timezone of environment in which code executes.

Mockito: verify order of invocations

Sometimes there is need to verify the order of invocations happened on mock object. Take a look at below RequestProcessor class. This class reads request from input stream, does some processing, write response to output stream and closes the connection.

public class RequestProcessor {
    private Socket socket;

    public RequestProcessor(Socket socket) {
        this.socket = socket;
    }

    public void process() {
        try {
            InputStream is = socket.getInputStream();
            String response = processRequest(is);

            PrintWriter pw = new PrintWriter(socket.getOutputStream());
            pw.append(response);
            pw.flush();
        } catch (IOException e) {
            // catch exception
        } finally {
            try {
                socket.close();
            } catch (IOException e) {}
        }
    }
  
    private String processRequest(InputStream is) {
        // process request and send response
    }
}

Here, we want to verify that in ideal case RequestProcessor should first read request from socket.getInputStream() and then after processing request, write response in socket.getOutputStream(). One way that comes in mind is to write test as:

@Test public void socketClosedInIdealCase() throws IOException {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    ByteArrayInputStream bais = new ByteArrayInputStream("a=b+c".getBytes());
  
    when(socketMock.getInputStream()).thenReturn(bais);
    when(socketMock.getOutputStream()).thenReturn(baos);

    RequestProcessor request = new RequestProcessor(socketMock);  
    request.process();

    // verify method invocations
    verify(socketMock).getInputStream();
    verify(socketMock).getOutputStream();  
}

At first this test seems to be verifying what is suppose to, but unfortunately this test will not detect if socket.getOutputStream() is moved before socket.getInputStream() as done in below code.

public void process() {
    try {
        OutputStream os = socket.getOutputStream()
        InputStream is = socket.getInputStream();
        String response = processRequest(is);
 
        // rest of the code
        } catch (IOException e) {
            // catch exception
        } finally {
            try {
                socket.close();
            } catch (IOException e) {}
        }
    }
}

This is because Mockito.verify() static method only verifies whether any invocation happened on mock object. It does not verifies order of invocation.

To make test verify invocation order, Mockito provides Mockito.inOrder static method. Using this method above test can be rewritten as:

@Test public void socketClosedInIdealCase() throws IOException {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    ByteArrayInputStream bais = new ByteArrayInputStream("a=b+c".getBytes());
  
    when(socketMock.getInputStream()).thenReturn(bais);
    when(socketMock.getOutputStream()).thenReturn(baos);

    RequestProcessor request = new RequestProcessor(socketMock);  
    request.process();

    // verify method invocations
    InOrder order = inOrder(socketMock);
    order.verify(socketMock).getInputStream();
    order.verify(socketMock).getOutputStream();
}

If the order of invocation is changed in RequestProcessor.process() method, this test will fail.

Below is complete code.

Mockito: Two simple ways to create mock

Mockito is the simplest, cleanest and easiest to start with among other mocking frameworks present in java world. Being so simple, it still tries to make our test more cleaner and readable by providing two simple ways to create mocks depending upon the need. Let's look into those.

1. Using static mock method

Socket socketMock = mock(Socket.class);

This is most common way to create mock. But what if mock is to be created and used in each test method in test class? One way to do is declare it as field and initialize it before test method is called. Something like this:

public class RequestProcessorTest {
    private Socket socketMock;

    @Before public void init() {
        socketMock = mock(Socket.class);
    }
}

This looks simple and clean, but what if there are more than one field to be mocked? Create mock for each in init(). It's simple. But is there more simpler way to combine declaration and initialization process? Yes! that takes us to second point.

2. Using @Mock annotation

@Mock annotation is shorthand for creating mock. This code shows how to create mocks using annotation.

public class RequestProcessorTest {
    @Mock private Socket socketMock;

    @Before public void initMock() {
        MockitoAnnotations.initMocks(this);
    }
}

MockitoAnnotations.initMocks() is important here. It initializes all fields with @Mock annotation. In above code it creates mock of Socket and assigns it to socketMock. Using @Mock annotation has below listed advantages( as specified in mockito java docs):

• Minimizes repetitive mock creation code.
• Makes the test class more readable.
• Makes the verification error easier to read because the field name is used to identify the mock.

So when to use #1 and #2? As listed in java docs of @Mock annotation, if mock creation code is repetitive, I prefer to use #2 otherwise #1.

Why Ruby?

I don't completely agree with the presenter on monkey patching and Java, but was an interesting presentation.

dup and clone: What's the difference?

dup and clone are used in ruby to create duplicate/clone of an object. So what's the difference between them? They differ in how they operate on frozen object. When frozen object is cloned using clone, the cloned object remains frozen, while when frozen object is duplicated using dup, the duplicated object is not frozen.

Ruby: freezing your object

Before diving in, lets look into what are mutable and immutable objects.

Mutable object is object that can be modified anytime during its life time. Immutable object is object that cannot be modified after it is created.

In ruby object can be made immutable anytime using freeze method. Once the object is frozen, it cannot be modified further in its life time. Any attempt to modify frozen object results in TypeError. Let's take a look at simple example of freezing a string object.


Once str is frozen there is no way it can be unfrozen.

Ruby also provides frozen? method to check whether object is frozen or not.


One important point to take a note about freeze method here is that freeze makes object immutable and not object reference variable. Take a look at below code.


obj1 and obj3 points to one instance of FreezeTest and obj2 points to another instance of FreezeTest. Once obj1.freeze is invoked, instance of FreezeTest to which obj1 and obj3 are pointing is frozen and not obj1 and obj3 variables. Both these variables can be modified to point to any other instance as seen in above code.


So where can freeze method be useful? Two places I can think of

1. Creating a true constant object: By true constant, I mean constant variable that refer to immutable object. Lets take example from rails. request.rb defines LOCALHOST constant as
   
   LOCALHOST = [/^127\.0\.0\.\d{1,3}$/, "::1", /^0:0:0:0:0:0:0:1(%.*)?$/].freeze
   
   By freezing array to which LOCALHOST points, rails makes sure that no one should be able to modify definition of localhost by removing and adding elements to array.
   
   
2. Using object as hash key: Once object is used as hash key, we want to make sure that it's hash is not changed otherwise it will be difficult to find value associated with it. One of the way to achieve this is by freezing object and then using it as hash key.

What All Rubyist Should Know About Threads

Google App Engine, things to know

Goodbye Google App Engine (GAE) provides some details one should be aware before starting using GAE as platform for new killer web app.

Using ActiveRecord without Rails

Following ruby code shows how to use active record in non rails environment.



Contents of database.yml: