Strong Typing vs. Strong Integration Testing

In those days when I worked with static typing languages and only looked at dynamic ones, I came across a good article. I mean "Strong Typing vs. Strong Testing". The main thought of this article is: tests can compensate weakness of dynamic languages in large projects. And they do compensate.

But a few years ago I didn't pay attention to a subtle detail. And now I realize there is a little mistake in the article.

When Bruce Eckel tells about tests he means unit tests. He uses adjective "unit" a few times. But unit tests work with isolated modules (classes or objects in this context). All dependencies of the class under tests should be decoupled. You should test the class, not its dependencies.

On the other hand the most problems with weak types happen in the boundary of modules. When a programmer writes or modifies code within the class he/she has strong situation awareness. Much better chance to get a wrong argument from without the class.

And poor unit tests cannot help with this problem. The class neighbors are artificial and well tailored. They are stubbed. They returns only appropriate values.

Integration tests behave in other mode. They run a whole bunch of modules. So the likelihood of getting a wrong type increases in times. Troubles come from a long and error prone call chain. And a developer has a good chance to see broken code and to fix it.

Thus integration tests handle this problem much better then unit tests. And I would correct the original article title a little bit. Hmm... At least I do this with my blog article.