Some time ago I described how I moved away from the JUnit frame­work as the tool moved from unit test­ing to func­tional test­ing. Now I've begun replac­ing two other frame­works that I've out­grown: JSys­tem and Castor.

JSys­tem is a way of spec­i­fy­ing options for over­all sys­tem test­ing. It gen­er­ates objects at run­time from an XML for­mat. It works pretty well if you have a sta­tic test setup that only devel­op­ers might have to inter­act with. How­ever, it makes a lot of assump­tions by default that are extremely dif­fi­cult to change. Assump­tions of con­fig­u­ra­tion file loca­tion, nam­ing, and struc­ture are built deep into the code — it's just not con­fig­urable at all. What few things you can change have to be done via sys­tem prop­er­ties and are mostly ignored unless the defaults actu­ally fail. There is a Sut con­fig­u­ra­tion file to allow the test tool's user to spec­ify objects and val­ues for dynamic instan­ti­a­tion, but JSys­tems requires extra info info in the Sut file that is con­fus­ing and unnec­es­sary for an end user, like the full class name of each defined object. JSys­tem could be nice if it didn't make so many hard­coded assumptions.

<post exam­ple here tomorrow…>

As for Cas­tor — it is a really slick sys­tem for build­ing objects straight from XML or from a real DTD with the abil­ity to rewrite them with changes back to XML. The cas­tor tool gen­er­ates objects that do all the XML pack­ing and unpack­ing; Each Castor-generated object knows how to mar­shal and unmar­shal itself. They are pretty easy to mod­ify and extend. How­ever the cas­tor library pushes 2 megs in size. The truth is, I'm using a very small part of the func­tion­al­ity of Cas­tor. I hate includ­ing it for the small por­tion of the code that needs it, because it is about 20% of the size of the entire con­tents of the test tool package.

If I can strip out JSys­tem and Cas­tor and all the libraries they depend on I can cut the pack­age size in half and get rid of a lot of messy hacks that exist only to work around JSystem's stupidities.

So my cur­rent side project is a replace­ment for the both of them. It reads in an XML file and pushes the data val­ues into objects via reflec­tion, all done at run­time. It requires a sim­ple map­ping file that for now is just this:

nbbs -> src.NbbsSystemObject
cpe -> src.CpeObject

This says that an <nbbs> node in the XML maps to the src.NbbsSystemObject class. When the DOM parser encoun­ters an nbbs tag it instan­ti­ates that object via reflec­tion. Then for each sub-element like, say, url and api­Path nodes it searches the Nbb­sSys­te­mOb­ject for those fields and sets their value via reflec­tion. If they are pri­vate it tem­porar­ily ren­ders them acces­si­ble to set the value.

Thus this new tool makes no assump­tions about the XML it will have to process. It just deals with it on a lazy basis. It's really basic right now, but amaz­ingly the darn thing works. It suc­cess­fully turned the fol­low­ing XML into an NBBS object and 2 CPE objects, which is exactly what I cur­rently get from the entire JSys­tem framework:

<sut>
<nbbs>
<url>http://nbbsserverurl</url>
<apiPath>/apipath</apiPath>
</nbbs>

<cpe>
<serialNumber>19687076</serialNumber>
<model>3347NWG</model>
</cpe>

<cpe>
<serialNumber>9756472</serialNumber>
<model>3397GP</model>
</cpe>

</sut>

Lines of code required: 90. Obvi­ously there is lots to do with it, but it works. First thing tomor­row I'm rip­ping out the JSys­tem and Cas­tor code. It's gonna be great.