Silent Pair Programming

On Thursday 31 October I participated in a Silent Pair Programming event organised by the London Software Craftsmanship community. During the sessions pairs are not allowed to talk about the problem and they can only discuss secondary issues as the IDE, keyboard shortcuts, etc. The goal of the exercise is to communicate with code and maximise its readability. Here are a couple of my learnings from the session.

If the partner writes a test which requires too much of implementation code at once, one way to solve it is to make it pass by hardcoding the response and then writing a smaller test. Once implemented, the following test should prove the hardcoded response insufficient and in consequence to its removal by generalising the production code.

When working on the production code, it might be worth following Kent Beck's Composed Method pattern (from "Smalltalk: Best Practices and Patterns"). That is, let your partner follow your thoughts by implementing the method (almost) entirely with well-named private methods and variables. Programming language specific features and APIs should be hidden in the private methods. The reason is that they are often too generic to convey the intent. Once the test is green, the pair might want to minimise the code by inlining some of the private methods, if the underlying generic code does not obscure the readability.

If you don't understand what a piece of code written by your partner does, you might want to select it in the editor and hand over the keyboard to them, so that they refactor it towards more clarity.

If you can think of any other tips for Silent Pair Programming sessions, please feel free to post them in the comments :)

Literals and variables in unit testing

Today at the Path11 Book Club we talked about chapters 21 and 22 of the book "Growing Object-Oriented Systems Guided By Tests" by S. Freeman and Nat Pryce.

In the part Literals and Variables of the chapter 21 the authors advise to use variables/constants in place of meaningless literals:

...test code tends to be more concrete than production code, which means it has more literal values. Literal values without explanation can be difficult to understand because the programmer has to interpret whether a particular value is significant (e.g. just outside the allowed range) or just an arbitrary placeholder to trace behavior (e.g. should be doubled and passed on to a peer).
...
One solution is to allocate literal values to variables and constants with names that describe their function.

While this rule is rather self-explanatory, I have noticed some interesting pattern. When I do TDD pretty often in the refactoring phase I go through the test code and replace literals with constants (unless it obscures the readability). What happens is 2 kinds of constants emerge:

• Example Constants (one value out of many possible)

public static final String USER_NAME = "Joe"; //in fact it could be also "John" or "Sue"
public static final int INVALID_ID = 666; //in fact it could be also 667, 668, 669 and so on...

• Significant Constants (concrete value having special meaning)

public static final String ATTR_EVENT_ID = "eventId"; // significant value
public static final int AGE_OF_CONSENT = 18; // significant value

Significant Constants will be very often needed in both test and implementation. So they can be moved to the implementation class and then referred to in the test class.

On the other hand, Example Constants will usually stay only in the test code.

Here is an example using Spring MVC:

Update: as pointed out in the comments, sharing Significant Constants in both tests and implementations carries the risk of uncaught errors when editing the constant value. The safest way is indeed to have the test class be entirely a specification, thus defining its own constants/variables and not refer to the implementation class.

PS: don't forget to visit awesome Path11 Book Club :)