The book is out!

Toni, Felix and the gang invited me to contribute to the brand new book. The Practices of the Proper Christian Programmer will be available on Amazon shortly!

implementing kaizen

My friend Tomek is kean on lean and the Japanese philosophy of continuous improvement. He preaches about kaizen every now and then. Once upon a time he sat in the pub with his mate, a guy who owns a construction company. The guy caught the bait and read the book. Here is a short story what happened to his company when he started implementing kaizen.

My friend’s friend borrowed some ideas known from the Toyota Production System, where everyone can suggest improvements to the process. So he asked all his employees how could they improve the way they work. Employees said they prefer to be paid for the actual work they do instead of being on the hourly rate. The company owner was reluctant to implement this idea. He was afraid that he would have to pay his employees much more than before.

Reluctantly, he let go and changed the pay model according to his employees suggestions.

Here’s the outcome:

1. The productivity boosted. Employees use to embed 40 pales during irrigation works. Now they manage 200…

2. Misbehavior ended. The company owner had to get up at 5AM to arrive at the site before his employees. If he was late, the guys started drinking making the day pretty much useless. Now they never drink at work and the owner arrives at site when he wants…

3. Employees motivate and watch each other. Previously, some guys worked more than others. Some didn’t work at all when the owner was not watching. Finally, there were occasions when someone purposely damaged some machines just to slack around a bit longer. Now everyone works equally hard because the team has to deliver. If someone stands out with poor work, the entire team tells him off.

4. The team self-organizes. Previously, the employees didn’t care what they do throughout the day. They had to be told what to do. Now they discuss and plan in the morning what they execute during the day. It looks like stand-up meetings are not restricted to IT…

5. Motivation increased. Previously, employees didn’t want to work on Saturdays or when there was a bad weather. Now the rain nor the Saturday don’t bother them at all.

6. Morale increased. Employees deliver faster which makes them proud. Also, they are paid more which makes them happy. Do you think the company owner is also happier? I wonder how much he misses getting up at 5AM…

7. He pays them just 60% more…

This is my favorite lesson learned from this true story (you tell me what is yours):

The role of leadership is listening to the people and trusting them when it comes to implementing their ideas.

let’s spy

Following Gerard Meszaros: “Good names help us communicate the concepts”.

There is this Test Spy framework I worked on lately. Unfortunately, it doesn’t use ‘test spy’ metaphor at all. It talks about ‘mocks’ all the time. Some even say that the name of the library has something to do with mocking…

Was I just a foolish ignorant who didn’t want to acknowledge different kinds of mocks. Ouch! I should say: Test Doubles. In case you haven’t heard about Doubles: all those substitutes of real objects that make testing simpler or faster or more maintainable. I like them because they shrink the unit under test and make it easier to test.

I like simplicity. Introducing new concepts doesn’t make things simple. Do I really need Double, Dummy, Fake, Mock, Spy and Stub to write decent code? On the other hand, I definitely need them to communicate how to write decent code.

At the back of my weird mind I used to think that Test Double breakdown was a bit disconnected from the reality where subtle differences are blurred (and the existing tools/libraries didn’t really reduce the confusion). I tried to keep things plain but I reached the boundary: trying to keep things simple (and sticking to mocks and stubs) actually could have increased the confusion and made things complicated.

That’s why I’m about to sort out Mockito terminology. Better late than never, right?

In all of my previous posts ‘Mockito mock’ should be read ‘Test Spy’. But what’s the Test Spy anyway? Or better: what’s the difference between a Test Spy and a Mock? Both serve verifying interactions but the Spy is simple, lightweight and it gives very natural testing experience, close to good old assertions. Sounds interesting? Have a look at some of my previous rants or read this excellent post by Hamlet D’Arcy (don’t miss Collaborator Continuum).

Let’s get back to my favourite Test Spy Framework. Do you think following changes makes things simpler and easier to understand (I don’t really know the answer…):

@Mock -> @Spy

mock(Foo.class) -> createSpy(Foo.class)

Mockito

I’m a mockist but existing mock frameworks just don’t appeal to me. They spoil my TDD experience. They harm code readability. I needed something better. That’s why I came up with Mockito.

Syntax

Here is a what I think about mocking syntax:

• Let’s keep it simple: interactions are method calls. There is no point in building sophisticated mocking language for method calls in Java. There is already a language for that. It’s called Java.
• The less DSL the better. Interactions are just method calls. Method calls are simple, DSL is complex.
• No Strings for methods. I spent more time reading code than writing it. Therefore I want the code to be readable. String literals pretending to be methods cannot compete with actual method calls. Even IDEs decorate literals differently so my mind will always adopt the real method call quicker than any literal trying to impersonate a method.
• No anonymous inner classes. They bring more indentation, more curly brackets, more code, more noise. Did I mention that I spent more time reading code?
• Painless refactoring. Renaming a method should not break my tests.

That’s why I really like the syntax of EasyMock.

Long journey from EasyMock to Mockito

I was brought up on EasyMock. Normal kids got milk I got classes to test. Over the years on different projects I saw idyllic world of hand crafted stubs being overthrown by EasyMocks. On other project, jmock was doing fine until he got a Chuck’s roundhouse kick to the face by EasyMock. Finally, I saw resentment to EasyMock and triumphatic comeback of hand crafted stubs… Sometimes the resentment to EasyMock was a bit naive (“My class has 10 dependencies and is difficult to test. Therefore EasyMock sucks”). Sometimes it was clearly righteous…

Here is what I wanted to achieve with Mockito so that it suits me better in test-driving code the way I like:

Focused testing. Should let me focus test methods on specific behavior/interaction. Should minimize distractions like expecting/recording irrelevant interactions.

Separation of stubbing and verification. Should let me code in line with intuition: stub before execution, selectively verify interactions afterwards. I don’t want any verification-related code before execution.

Explicit language. Verification and stubbing code should be easy to discern, should distinguish from ordinary method calls / from any supporting code / assertions.

Simple stubbing model. Should bring the simplicity of good old hand crafted stubs without the burden of actually implementing a class. Rather than verifying stubs I want to focus on testing if stubbed value is used correctly.

Only one type of mock, one way of creating mocks. So that it’s easy to share setup.

No framework-supporting code. No record(), replay() methods, no alien control/context objects. These don’t bring any value to the game.

Slim API. So that anyone can use it efficiently and produce clean code. API should push back if someone is trying to do something too smart: if the class is difficult to test – refactor the class.

Explicit errors. Verification errors should always point stack trace to failed interaction. I want to click on first stack element and navigate to failed interaction.

Clean stack trace. Part of TDDing is reading stack traces. It’s Red-Green-Refactor after all – I’ve got stack trace when it’s red. Stack trace should always be clean and hide irrelevant internals of a library. Although modern IDE can help here, I’d rather not depend on IDE neither on competence in using IDE…

EasyMock is a decent piece of software, credits go to kick-ass people who wrote it. Initial hacks on Mockito were done on top of the EasyMock code but since then I rewrote most of the codebase. Enjoy.

is private method an antipattern

After a conversation with my friend and after a cursory google search, here are my thoughts:

‘Private method a smell’ seemed to be ignited with the birth of TDD. Test-infected people wanted to know how to test their private methods. Gee… it’s not easy so the question evolved from ‘how‘ into ‘why‘: Why to test private method? Most of TDDers would answer instantly: don’t do it. Yet again TDD changed the way we craft software and re-evaluated the private methods :)

Test-driven software tends to have less private methods. Shouldn’t we have a metric like: private methods to public methods ratio? I wonder what would be the output for some open source projects (like spring – famous for its clean code).

So, is private method an antipattern or not!?

If the class is so complex that it needs private methods, shouldn’t we aim to pull some of that complexity into its own class?

The code never lies: We looked at several distinctly big classes and put their private methods under magnifying glass. Guess what… Some of the private methods where clear candidates to refactor out to separate class. In one case we even moved whole private method, without a single change, into separate class ;)

Privacy may be an antipattern. Look at your private methods – I bet some of them should be public methods of different objects.