Jake Herringbone

Assert, Validate, Precondition

Several recent posts have been about what I’d like to see in a programming language, and those ideas prompted me to code. What I’ve been creating is a new programming language, very similar to Java and targetted to the JVM, but with these testability and best practice ideas included.

• Immutability – final should be the default
• Testing – unit tests should be in the core language, not a library
• Dependency Injection: class parameters

The language is called Nil, and the project is hosted at http://nil.googlecode.com.

Some ideas come from work, where I contribute to Testability Explorer (http://testability-explorer.googlecode.com), some come from blogs I read like this post from Michael Feathers (author of Working Efectively with Legacy Code) A Wish for the next Mainstream Programming Language. Some are inspired by other languages, like Objective-C, ActionScript, and Scala.

I should afford some introspection here: I realize that, as Steve Yegge says, “your language is doomed to fail, with probability 1 minus epsilon.” So even if contributors and I produce something useful, it’s not going to be used. That’s fine, there are lots of little-known languages with a small, über-geek following.

So, today’s idea, is about assertions. In testing, there are various libraries modelled after JUnit, which is nice, and as I’ve said, the language could make life a little easier by allowing the test to live in the class it tests.

Another thing the language could do is provide a context-sensitive assertThat() method. I’ve seen various API’s, like Springs Validator class, and Preconditions in Google Collections, which are asserts in your production code. I like these, just because you fail faster. It’s also a nice executable way to document the preconditions of your method. You use them because you don’t want to depend on JUnit. But that’s silly. Why not have the same powerful API to express your expectations in your test that you have in production code? If assertThat() was a method automatically mixed into all classes, then it just fails the current test if called in a test, and it throws an IllegalStateException with the same lovely message when called in production code.

Another idea: what if a method could define an internal DSL? Then the equals() and isA() and so on don’t have to be imported into the namespace of the test. When you call assertThat(“a”, isA(String.class)), you can’t resolve the isA() method, but when assertThat() evaluates its arguments, the isA() method is defined in that scope. IDE’s would need an easy way to find methods that are legal in such a scope, but that seems doable. The advantage is that the isA() method doesn’t clutter the completions when you’re not inside assertThat()! The API appears to have only the assertThat() method.

I’ll go code some of this now!

No comments yet.

Leave a comment