Testing Influences Design

I was talking to a co-worker the other day about JavaScript. We’ve been experimenting with a new rendering technology — one that allows us to JUnit our HTML assets outside of the servlet container — and I’ve really enjoyed the ability to create test artifacts without having to resort to (often, much slower) HttpUnit tests.

But then we got to the question of JavaScript. Sometimes there’s a critical piece of functionality that uses JavaScript to do its thing. Now, a lot could be said about whether or not a web application should depend on JavaScript — I’d be content to leave that discussion for another time.

Anyway, we asked ourselves, what does HttpUnit do? It supports JavaScript by embedding Mozilla’s Rhino implementation of JavaScript.

“Well,” I said, “we could add Rhino to our test framework — support JavaScript the way HttpUnit does!”

“But,” my co-worker countered, “if we do that, then we need to impose a design restriction on our JavaScript that it must be compatible with Rhino’s implementation. Doesn’t it seem wrong to make design constraints based solely on testing needs?”

I blinked, and thought about the question because I think it reflects a very deeply-rooted feeling about testing — that testing is somehow secondary to application code; that it’s somehow gravy on top of the real meat.

“I don’t think so,” I answered. “I think that recognizing the constraints imposed by testing are valid influencers of design.”

And the more I thought about it, the more I started to recognize that the ability to test is one of the things that attracts me to systems designed on top of Spring, rather than systems designed on top of EJB. And that makes me feel like the design of Spring is better than the design of EJB.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply