Code Blocks

eitan — Tue, 17 Jan 2006 17:28:33 -0600

I'm about to check out TestNG for the first time. I have the documentation printed in front of me and hope to take it for a spin shortly. So I read the TestNG web site's front page. I followed the three links from the front page to three blog entries by Cedric Beust that essentially describe issues he has with JUnit. Cedric's arguments are not convincing.

Here's is my understanding, let me know if I'm wrong:

One of the principal ideas in JUnit is to use the Method as as an analog to a generic block of code: in this case, a test. A method is a test. Don't think of a method as a method. Think of it as a test. Cedric is confused, and rightly so: JUnit test classes are not really classes in the way they were meant to be used by the language designers. He is confused that the class constructor is invoked once for every test that is run. That is, once per method. This is contrary to everything we've ever been taught about OO. Why is this so? Well, it's very simple. Imagine having to write a new class for every single test we wanted to run. It's tedious. It's overkill. The 1-1 mapping of method to test is much nicer. Furthermore, related tests can easily be grouped together in a class. JUnit does its magic behind the scenes, it uses reflection to introspect matching test methods and, in a sense, instruments them for testing. It invokes each in a specific context that ensures isolation from other tests, etc..

What I'm interested in though is in a generalization of JUnit. Grasping the essence of the pattern that JUnit employs is most important. The idea that one could, in general write a class with a bunch of methods and, separately, write a harness that does something else with each method, in a similar way, but where one can customize the context in which the block of code is run.

Take for example, the simple desire or need for someone to learn Hibernate. There's a lot of setup and tearndown that goes along with running all kinds of "tests" to learn the Hibernate API: obtaining a session, beginning a transaction, running the "test", commiting the transaction and "closing" the session. With a generalization of JUnit I would write tests that could be run in a slightly different context where each test method is called in a context that repeatedly does the mundane: opens the session, begins the transaction, calls the block of code, commits the transaction, closes the session, and on to the next test.

Then you can use some kind of flexible runner application to pick which tests you'd like to run. Actually, that's one of the features of IntelliJ IDEA that I really love: the ability to run a single test directly from the IDE, without having to fuss with ant or setting anything up.

What I'm wondering at the moment is whether that "Generalization of JUnit" I'm seeking (though it might be actually trivial to write) is not called "The Spring Framework." Spring employs this pattern over and over again in all kinds of circumstances. What I don't know at the moment is whether one can customize it. This pattern actually is native to smalltalk and ruby (and requires no "framework" to enable). That explains why Kent Beck used it when he wrote JUnit.

Eitan Suez's Home: Code Blocks

Code Blocks