Sunday, March 09, 2008

Much to learn

So I'm investigating Ruby on Rails (vs my more extensive background in Java) and I see this quote:
A solid suite of unit tests is every bit as good, if not better than, static-type checking. Because all you want in type checking is confidence that you haven't made the basic mistakes. A good set of unit tests will provide that for you.

I'm wondering what I am missing? The most common mistake in the lack of type checking is outside the unit. One class makes the mistake of calling this other class and they don't understand the type of the variable. Most commonly, it changes after it was first written. In fact, that is why those with a preference for dynamic typing like so much - you can change it so easily and just add a method.

So here I have a series of Unit Tests that check for one thing on one object, and a series of unit tests that make sure that when an external object is called, it will be called with the right parameters. Then I go and change that other class and all of its unit tests. How do I validate that all calling code kept up? A text search? But method names can be duplicated all the time.

I just don't get how static typing of an interface is not the only way to ensure that changes are propogated throughout the project. Of course many times you don't have that luxury (like when you are calling web services). But it seems like a good thing to have, unit tests or not.

No comments: