Testing database interactions can be harder since the data can change. One option is to save the "baseline" results that you want to compare to as a WDDX file, then read that in and compare your test result to that baseline. You can add some logic that lets you trigger a recreation of the baselines if/when the actual database changes. You can write an abstract base Test CFC that the rest of your Tests extend and place this logic there so it is available to all of your test CFCs.
On 9/26/07, Alan <[EMAIL PROTECTED]> wrote: > > > You'd never have guessed I'd just read Kent Beck's TDD book eh? :-) > > As good a book as it is I'm still a bit in the dark about testing > certain types of objects. The same way that after reading Head First > Design Patterns it required Fowler's book on Enterprise Patterns to > fill in a lot of blanks. > > I have lots of DAO's in my model so want to get a good test case > written for one of them that I can use as my standard. > > On Sep 26, 4:34 pm, "Sam Larbi" <[EMAIL PROTECTED]> wrote: > > On 9/26/07, Brian Kotek <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > On 9/26/07, Alan <[EMAIL PROTECTED]> wrote: > > > > > > Questions are: > > > > > > 1) Is this a good approach? > > > > > Looks like TDD to me. That's the idea. Write a test. Make it pass. > Then > > > refactor as needed, now that you can test that your refactoring didn't > break > > > something. > > > > I agree - good approach. > > > > 2) When unit testing the service CFC should I use the business object > > > > > > it requires or mock it to ensure only the one CFC gets tested? > > > > > I would definitely Mock everything that is not the object being > tested. If > > > you don't do this, now you're testing a dependency tree, not an > individual > > > component. If something blows up, you're not sure where it went wrong > any > > > more because there are multiple files being tested. This is the whole > reason > > > I created ColdMock. It only works on CF8 since it uses > onMissingMethod(), > > > but you could easily install CF8 locally and get the benefit even if > you end > > > up deploying to CF 7. If you're interested, it's at RIAForge. > > > > If you write layer on top of layer and have good tests, it is normally > > pretty clear where the problem is. And if you are having problems in > the > > lower levels that those tests didn't catch (i.e., "something blows up > and > > you're not sure where it went wrong"), then those problems will still > exist > > - you will just be ignorant of them. > > > > I understand that it is a personal preference, but I limit my usage of > mocks > > to places that would take too long to test with the real object (I have > the > > real object test too -- for when I want to run it). I haven't been hurt > by > > using cfunit as an integration tester as well as unit tester. > > > > Regards, > > Sam > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
