ColdMock actually does keep track of methods and arguments, and will throw errors if you try to use a mock object in a way that wouldn't work against the original object.
On 9/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
