On 11/30/05, Jeff Chastain <[EMAIL PROTECTED]> wrote: > Now, any thoughts, ideas, suggestions on the actual test itself ... i.e. how > to actually test the DAO? >
I think there are three basic strategies. 1. EXERCISE ONLY PUBLIC METHODS Sean's option (a): Test create() by creating an object and then verifying that you can retreive() it, etc. The downside is you can't test any method in isolation. If one method breaks, you're likely to have mulitple failing tests. 2. INTERCEPT COMMUNICATION BETWEEN DAO AND DATABASE For example, have the DAO talk to a gateway that talks to the database. Then you could pass in a MockGateway and verify that the right methods are called with the right parameters. But that answer begs another question: How do you test the gateway? 3. INTERACT DIRECTLY WITH DATABASE Sean's options (b) and (c). You could use SQL to populate the database, and verify you can retrieve() an object you know should be there. This solution couples the test to the database, which isn't necessarily a bad thing. You're verifying that the DAO is persisting the data in a specific way, not just a way that allows the same DAO to recover the data. That's important if your app isn't the only client to the database. Also, you can test each method in isolation. If one method is broken, only the test(s) for that method will fail. Another common answer is to use a persistence framework. But a persitence framework would probably obviate the DAO. Otherwise, I think it falls under option 2. HTH, Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us ---------------------------------------------------------- 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]
