Thanks to both you and Sean for the feedback and links to the articles. Once I've finished flushing out the XML file and plan I'll send you a copy directly. I think I have the 1st pass of my XML file done and am working through the details on how I actually want the test unit to run. My plan at the moment to run a single testCRUDs function that does the create & updates, then reads and finally the deletes. The ideal goal is to leave db intact without any trace of the test records. I have this desire to be able to run the test unit on a production server to address the 'it runs in the test environment and not on production' syndrome. So I hoping this self cleaning approach might be able to assist with this goal. Success or failure I'll send the XML file and sample test unit over when I'm done so you can take a look and see if any pieces or ideas could be used or expanded upon for CFUnit.
Thanks again, Jason -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Blackburn Sent: Thursday, December 22, 2005 11:25 AM To: [email protected] Subject: Re: [CFCDev] Unit testing DAO CFC's On 12/22/05, Jason Daiger <[EMAIL PROTECTED]> wrote: > > I've been trying to use and implement test driven development on our > new project, via CFUnit, and am struggling w/ other developers on > several fronts, such as justifying the effort but that's another issue, ... I tried to list out some of the benefits of unit testing and TDD in my FA article, which might help some... http://www.fusionauthority.com/Techniques/Article.cfm/ArticleID:4560 > ... but the main > issue is how to efficiently test and exercise the DAO objects. I blogged about this a few weeks ago... http://www.rbdev.net/devblog/index.php?entry=entry051204-154123 If your DB supports stored procedure, I think that is you best avenue for testing DB scripts. You can form unit tests around the procedures themselves. That way you can test the SQL script in the language they are written in. I don't current use an SQL xUnit framework, we have something like custom unit test, but I plan on looking into that when i have time. I think the biggest problem with testing DB from within CFML is that it can be slow. Even if you have a SQL script that runs in less then 100ms, if you have 12 tests you need to run against it, then the test as a whole will be running at over s second. If you have a lot of these SQL scripts to test, then your unit tests may run VERY slowly. This make TDD cumbersome because you would not want to run a long test like that after every little change. If you don't have stored procedure support in your DB then what you are doing sound like a solid approach. If you find that your tests are getting a bit slow because of all the DB calls, I would suggest setting up two testing frameworks for your application – one that tests everything head-to-toe which will only be ran once a day or after major changes. And then a second that would only test key DB integrations that would be a part of your frequently ran TDD tests. I have done this before myself and it works well for larger apps. (PS: When you are done I would be interested in seeing how you did the XML, maybe there is something we can do in CFUnit to make that sort of thing easier) -- Rob Blackburn http://www.rbdev.net bn‰¶qN²rzu™¶qq¢®¶{v²ryu²²y~z” ²o {q¢®v¦y¢žÁ†Š¢jŠ~z²j•yÊryýu} ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
