Alan, Great that you're thinking this way. And reading some good books! Well, my 12 cents worth:
1. Testing DAOs - DBUnit with its Ant task can be handy for baselining a DB. It can be a pain to get it working and keep it working, though, so I have to say for testing DAOs I've rarely needed a clean test DB. Usually the sequence would go something like: . test new() . test save() . test delete() . use new() and save() to create some known test data, then test get(). Clean up using delete(). etc... Occasionally something goes horribly wrong and I'm left with some manual cleanup, but once delete() is working I'm pretty much on my way. If you use the setup() and teardown() methods in CFCUnit (or CFUnit) the test data will be cleaned up even if the test body crashes and burns. 2. Bottom up vs top down TDD - personal preference, I would tend to start with the service layer. This is purely because I find that we coders will almost automatically overengineer the lower layers if we start there. 3. Unit vs integration testing - do both! Mix and match! In Kent's book he talks about keeping a notepad where he basically adds things to his testing "stack" as he delves deeper into the system. When he's happy that he has got the lower level bits working, he unwinds the stack and resumes developing the higher level tests. The sequence can go like this: . write the end-to-end integration test (fails, cause none of the components exist or work) . stub out the dependencies (now have a unit test of the service layer) . TDD the parts of the dependant objects required to get this integration test to work (now have unit tests of all the dependant methods) . replace the stubs with the real objects (now have the working integration test) . but keep the stubbed version as well (so we still have the unit test) 4. Mocks vs stubs - just mentioning this because I had to scratch my head for a bit before making the terminology adjustment, so maybe someone else is also puzzled. In some circles, a mock object is an active test tool that tracks method calls and arguments and tells you if your object under test behaved itself properly. It seems that what we're talking about here is what the jMock types would call a stub, which just does the minimum required to implement an interface. Jaime Metcher On Sep 27, 2:03 am, "Brian Kotek" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
