Monday, 13 August 2007

I guess it's not a _really_ inventive thought. I've already heard about five times of strong testing instead of strong typing. However, there's yet another reason why testing and dynamic languages should be associated.

Testing gets child's easy when all your types are designed to change. Most techniques I can think of become simpler:

While testing state, you can prepare your fixtures fast, in just few lines of code. The features that enable you doing that are (in python) named arguments and its "open kimono" philosophy. Ruby gives you similar range of abilities (but I don't feel like I can enumarate them here:>)

Constructing mock objects, and monkey-patching is supported practically on language level in both python and ruby, with their module attributes subtitution, ruby's class opening and blocks and python's lambda. And duck typing of course.

Dynamic languages are suitable for building DSLs, which made it possible to create great behaviour testing frameworks (think Rspec)

The inspiration for this post (except for my boss' suggestion:>) came from the book xUnit Design Patterns, which focuses more on staticly typed languages. As I someone pointed out one day: DPs depend very much on the language you're using. And that's exactly the situation with that book. Many patterns become redundant in dynamic languages as you get the needed features for free.

Fixture teardown - in most cases is done by a garbage collector

Dependency Lookup, Test-specific subclass - become redundant since you can easily get to your object's guts in runtime

Test hook - it's not a problem to substitute your method with a function wrapping around it

Encapsulating logic into an object in order to make it testable is not needed, since you can manipulate methods quite easily

The conclusion, except obvious: "let's test" or less obvious "let's do more testing" is: It's really pleasant to know the reasons for which you enjoy your job so much.