Mock-based Unit testing revisit

The risk of using mock in Unit testing is that if you mock some behavior of an object, that assumption could easily break as the codebase keep evolving. If you forget to update those mocked setups when things change(this is always happening), you'll find your tests in a situation that it doesn't reflect production usage anymore.

Then what is the value of a test which doesn't reflect real production scenario?

Timezone change confuses Jenkins

Today we encountered a mess on Jenkins.

The significant issues were:

• Jenkins scheduled multiple builds of the same job in parallel which affected each other and failed quickly
• Newly scheduled builds didn't appear in Build History, as well as the Build Monitor screen on our wall projection

It's actually weird that although Build History doesn't update, when you go to Build Trend you can find them, which implies some underlying inconsistency in Jenkins' implementation.

Finally it's proven that it's caused by timezone change: from Australia/Melbourne to UTC, which confused Jenkins because last build happened in the future!

This apparently also affected Jenkins' change polling mechanism, which made it detected new changes everytime.

Argument capture in Mockito

Interestingly, the way that Mockito captures argument is afterwards! So you can basically write code like this:

   mock.doSomething(actualArgument);

   ArgumentCaptor argument = ArgumentCaptor.forClass(Person.class);
   verify(mock).doSomething(argument.capture());
   assertEquals("John", argument.getValue().getName());