Clap your hands say yeah right

If you haven’t already, lay your hands on Norwegian Wood by Haruki Murakami. Very subtle and modest in gestures and expression but with an unmistakable melancholic undertone. Really knocked me off my feet.

Some reviews of the book

Dear reader, if you by any chance would be at a position where you have great influence on future product development at Philips, Sony, Samsung, LG, Minolta etc, please listen carefully.

Lately whenever I lay my eyes (or ears, imagine that) on the output from almost any of the product emanating from the just mentioned companies I realize that there is a lot of signal processing going on under the hood. On average this is of course good and reasonable – the processing used is most likely picked for its ability to minimize the mean error (discretizing, aliasing, compression artifacts etc.) when pushing a set of reference signals through the product.

The problem is that not all signals are reference signals and surprisingly often the signal processing itself makes clearly visible and irritating traces. Sit close to a modern TV or zoom in on some of your digital photos and you will see what I am talking about.

Here comes my plead: Yes, add your nifty processing algorithms to your products, on average they do a good job! But please give us the possibility to turn them off. At times we might be better of with the inevitable discretizing artifacts instead…

I learned something today. Try the code below in java 1.4.2 and try to predict what the output will be before you run. 

[ftf w="470" h="270" def="js.xml"]
public static void main(String[] args) {
Runnable r = new Runnable() {
public void run() {
System.out.println(”RUNNING!”);
}
};
Thread t = new Thread(r);
t.start();

// sleep for a while
try {
Thread.sleep(1000);
}
catch (InterruptedException e) {
e.printStackTrace();
}

t.start();
}
[/ftf]

What I learnt (the hard way) was that a thread instance cannot be started twice and that this fact, that the underlying native thread is not started, is silently bypassed in the 1.4.2 JRE. No exception. No nothing. 

Thank you. Thank you.

When approaching already written code you will often be faced with dependency problems. Some parts of the dependencies are of that kind that you don’t want them in the test – they might be to heavily connected to hardware or applications servers etc., therefore making them hard to set up for automatic testing. Your task will be to make those dependencies pluggable. Here are some ways to accomplish that:

COMMON

• Configurability
  Suppose the class you are about to test has some behaviour that makes it hard to test. Make that behaviour optional by adding a “test-mode” switch to the code of that class. Pros: Easy and fast. Cons: Clutters the code with test-oriented details.
• Strategy
  Suppose you can isolate the behaviour that is problematic from a testing point of view. Cut that code out from the code and put it in a new class. Extract an interface from that new class and inject the interface into the class you wish to test. Now the problematic behaviour has become pluggable. At test time: just make a mock from the interface and inject that into the class instead. Pros: Does not clutter the code. Opens up the design. Cons: Can lead to class explosion if you need to cut out several parts.
• Dependency injection
  This is just a scaled up version of the strategy pattern. In the latter you injected variants of troublesome code to test. Dependency injection on the other hand lets you configure what dependencies (on other classes/modules etc.) the class has. Typically you might find that the class you wish to test Foo instantiates or acquires an instance of another troublesome class Bar. Foo is dependent on Bar and also has the control of how to create or acquire this instance. When applying the dependency injection pattern your goal is to relieve Foo of this task (creation or lookup of Bar) and instead provide the Bar instance via a setter or via the constructor of Foo. When you’ve done the Bar instance injectable it is easy to either mock Bar directly (see easymock+extensions for instance) or create an interface of Bar and a stubbed or mocked version to inject instead… Pros: Opens up the design.
• Factory Method
  In the last example we relieved Foo from creating or acquiring Bar by injection. Often this instead already has been done via a factory method. By applying the factory method pattern the Foo does not have to know how to create or acquire Bar. Unfortunately factory method keeps the design more closed when comparing it to dependency injection and from the testing point of view we have to turn or focus to the factory class to be able to mock Bar. In the factory we can apply either of the above mentioned methods (configuration of the factory or injection of a temporary stand-in MockBar class).

LESS COMMON (for good reasons too)

• Template Method
  Cut out the hard-to-test functionality into a method of its own in the class Foo you wish to test. Now pull up (see your refactoring menu) an abstract class AbstractFoo from Foo containing all methods except the hard-to-test one. Create a new subclass of AbstractFoo with the name MockFoo where you change the behaviour of the hard-to-test functionality. Test MockFoo. Cons: Several things are troublesome here… In the test it will look like you are testing the Mock instead of the actual class. Moreover you had to make a rather unmotivated subclassing (i.e. the inheritance will not really represent a generalization).
• Overriding
  Same as above but extending the class directly and using override to mock behaviour. Same problems with this one.

…and of course sometimes it is appropriate to make combinations.