I have unit tests for all my xslt. I'm not using XSLTUnit (which is a fine program)--in my case, for each xslt file, I have a one or more test input files and corresponding reference files which are the expected result when I run the transform. I use file names/extensions to group them:
myScript.xslt myScript.simpleTest.xml myScript.simpleTest.ref myScript.complexTest.xml myScript.complexTest.ref I use a combination of batch jobs and ant scripts to match up the files, run the tests, and compare the results. I don't always do test-first--sometimes it's just easier to test your code inside your app. So what I often do is write the code, test it in the app, and then write the tests. I then back out my change, and run the tests again. The tests should fail--if they don't, I've done something wrong in my test code. I then reintroduce my changes one bit at a time, and make sure sure my tests start to succeed again. I think unit testing xslt's is a great thing. HTH, Steve > -----Original Message----- > From: Robert Leftwich [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 28, 2002 9:58 PM > To: [EMAIL PROTECTED] > Subject: Unit testing xslt > > > Given Cocoon's big focus on transforms, I was wondering if > anyone is using > unit tests and/or test-first design when developing their xslt? I'd > appreciate any comments on its effectiveness and what tools > you are using > (XSLTunit for example?). > > Robert > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>