Showing posts with label .Net. Show all posts
Showing posts with label .Net. Show all posts

Monday, April 02, 2007

Javascript testing with NUnit

I've been looking around for a good way to test Javascript functions.

There are at least two if not more versions of JSUnit, one here and the other here. But there is one fundamental requirement I have for any unit testing framework, and that is that it has to integrate into an automated build script. For example, suppose you're using CruiseControl. It's got an NUnit step in it; once you write up your tests, it's the matter of a few minutes' configuration to get them running as part of the build, and it's very satisfying to watch the test counts grow as more builds are done. 117 tests run, no failures. 123 tests run, no failures. 135 tests run, no failures.

So if the framework doesn't work with automated builds, it's no good to me. Do they? I'm not sure. Edward Hieatt's version seems primarily to require a browser, although he does provide a JSUnit Server which appears to be designed to work from Ant or Java, but doesn't have any particular support for Nant or ASP.Net that I could find. Jörg Schaible's version is even less able to work in Windows; starting from the download which is only provided in tar.gz format. The documentation states that it can be run from the command line; if so that's easily adaptable to an automated build, but I didn't even take the trouble to download it, suspecting that it wouldn't even run on Windows.

So I was looking around for other alternatives, and I ran across this post. I'm sure that not everything you can write in Javascript can be evaluated by the .Net Javascript evaluator, but when you write a lot of tests you get used to keeping functionality nicely isolated.

I'm not sure what the best way to use this is. My first couple of tests have the Javascript in the ASP.Net codebehind file, where they can be unit tested at test time and Response.Write-n at runtime; but there's a few other possibilities; keeping all the Javascript in a separate file to be read in at test time, and using it as an include at runtime perhaps.

So I have a lot of work to do on this technique. But it seems promising!

Monday, March 12, 2007

Generating classes from XML in .Net

The Oracle version of SQL has some nice keywords for returning your data in an XML format. (I suppose the other servers do too, but I've not used that feature.) When I get the XML back, I want to turn the XML into a set of business objects for easy serialization. XSD is the tool for that. Write the XML to a file, run XSD on it to generate a schema, then run XSD /c to generate the C# class file, and you've got a nice class. You can muck around with the XMLElement and XMLAttribute attributes to create nice field names, and 30 seconds to put together a static Get() method that returns a class from the XML.

Except it didn't work. The serializer threw a File Not Found error. When the XMLSerializer class has a new type it needs to serialize, it just generates the code on-the-fly and throws it into a new assembly with a name like olkdzxc.dll, and returns the class from it; but when I called the serializer, it told me that olkdzxc.dll wasn't found. Very mysterious.

Luckily, I remembered Chris Sells' old tool that was made for debugging exactly this problem, XMLSerializerPreCompiler, which lets you see the compiler errors that occur while the code is being serialized, and one of those led me to the problem: When generating the class code for an array of objects, XSD was adding an extra set of brackets in. So instead of having a class member myFoo[], I had a member myFoo[][]. Why did XSD do this? I have a hard time believing it's just a silly bug. I'd love to hear if anyone knows.