Your point about changing global methods is totally valid, and experienced users of dynamic languages often frown on too much of this practice. I learned this the ugly way when I inherited code from a JavaScript programmer who wrote tons of methods into Object.prototype (*gasp*). However, judicious use of prototypes in JS or things like open classes in Ruby can yield extremely positive results that make life much easier for everyone. I mean, c’mon, doesn’t every Java programmer in the world want a string method that matches against a regex already?

Of course, if you design for testability from the start, then this point is obviously moot. But that’s not the world everyone lives in… or is thrown into.

Great point about instance method overriding, and you are right there is no global state. However, instance method overriding is equivalent to overriding methods in tests in java using anonymous inner classes. Most TDD frown upon that. The other issues is more complex. If you mix object creation with application logic than you can instantiate the object under test and you can override instance method on the object. But if the object-under-test instantiates other objects you don’t have a reference to those objects, and hence you can’t override the instance methods there.

The main point I want to get to is that you can’t leave testability as after the fact. Testability is something you have to bake into the design of your application. You have to think about it from day one. Now, it is true that there are more tricks you can use to tests your application in dynamic languages, but I feel that those tricks are all work around to the core problem of untestable design. But it differently, you can’t not think about testing in dynamic languages.

The other important point is that testing should be done by wiring objects in tests differently than in production. By replacing key objects with test-doubles your test graph of objects can be controlled. Dynamic languages allow you to change code at runtime, but now you are testing by modifying code rather than wiring the code differently. Since you are modifying code it is very easy to get lost as to what is real and what is replaced code. You no longer have clear separation of objects.

I think what is true is this: In dynamic languages you can write tests for badly designed code, something which is very hard to do in Static languages. However, the tests you write will be brittle and will rely on global state. Claiming that it is more testable is simply missing the point that testability is something which needs to be baked into the codebase.

This provides a useful extra seam that me and my colleagues use a lot during unit-testing, and it doesn’t affect global state. The object in question will be out of scope by the end of the test, and a new one constructed for each subsequent test.