Hmmm... I agree with Jari--thought *should* go into unit testing. And Latka/JXUnit already do some XML integration.
If you're using NetBeans, it has a nifty extension that generates TestCase skeletons for you--including subclassing abstract classes so that you can test superclass logic. I highly recommend it for taking out the boring part of unit testing (writing the suite method, the main method, etc.) We have a task on the todo list for creating some Custom Cactus extensions to this extension to automate the creation of Cactus unit tests (with begin and end methods) as well. Cheers, Nick -----Original Message----- From: Brian Agnew [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 03, 2001 4:06 AM To: [EMAIL PROTECTED] Subject: Re: Junit: Automatic Framework for generating TestCase file [I think the comment about addressing JUnit with these thoughts rather than the Cactus list is a valid one]. But as the thread persists (!) I agree that you don't want to remove the 'thought' behind generating tests. But I'd like to be able to tie the tests more closely to the code being tested. Perhaps tag the code to be tested with appropriate test data/sets etc. At the moment (and I have limited experience of JUnit and Cactus) I have a TestCase class separate from the classes I'm testing. The point below about the test cases acting as an example of how to use the code is a reasonable one. But beyond that I haven't given this any thought. It would definitely require some in-depth consideration. --- Jari Worsley <[EMAIL PROTECTED]> wrote: > Karthik Kumar wrote: > > > > Hello, > > > > --- Brian Agnew <[EMAIL PROTECTED]> wrote: > > > I was thinkking on a similar line, but thought of the following: > > > > > > Use custom Javadoc tags for each method, indicating testability, > parameters, > > > expected results, messages etc. We then have a custom Javadoc doclet. > When we > > > want a TestCase we run Javadoc with the custom doclet over the code and > > > create > > > the test cases automatically. > > > > > > This can be made part of the build. The test parameters etc. are tied > > > directly > > > to the code, so it's pretty obvious what's going on. > > > > > > Brian > > Using custom javadoc tags seems a great idea. Because that would give a > great > > control to the programmer over the code he writes the same way he writes > doc. > > for his code. > > I'm not sure about automating the writing of tests - provide a framework > for getting data out of a file if you have many tests to run (which > sounds a bit like an functional or integration test to me?). Have a look > at jxunit on sourceforge, or perhaps the latka project in > jakarta-commons too. > > I wouldn't be amazingly keen on using custom tags to create the tests - > it means you lose some of the point of writing unit tests in the first > place, namely that the test then acts as an example of how to use the > tested class. > - i.e. with a class Broker and test of TestBroker, the code in > TestBroker provides any programmer who wants to use Broker with actual > code examples of how to use the API. If you use tags you would lose that > advantage. > - also, i think you need to be careful about how "easy" or "automated" > you make writing tests, otherwise you're in danger of losing another of > the main points about them - by being made to think about each > individual test of a class, you learn more about the class that you are > writing. So it shouldn't be a "chore" to write tests, but more a regular > feature of how you work during the day, to make your job easier :) > > ( or do you just use the javadoc tags to generate TestCases, then flesh > out the generated code if need be?) > > > > Jari > -- > Jari Worsley > Senior Programmer > Hyperlink Interactive Ltd ===== Brian Agnew http://www.oopsconsultancy.com OOPS Consultancy Ltd [EMAIL PROTECTED] +44 (0)7720 397526 ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
