Yeah, thanks everyone for their input. I'm still trying to get my head around this so have files all these posts for further review in January!
Happy Holidays, Peter On 12/22/06 1:21 PM, "Sammy Larbi" <[EMAIL PROTECTED]> wrote: > Thanks Jeff. I had thought you were simply asking about dependencies in > TDD. I enjoyed the discussion anyway, and learned a thing or two, so > thanks to you, as well as everyone else who participated. > > -Sam > > > Jeff D. Chastain wrote, On 12/22/2006 11:40 AM: >> Sam - >> >> All of your points are valid. This is another one of those areas >> where there is not a black and white, right vs. wrong answer. As long >> as the app goes out the door, on time, on budget, and meets the specs, >> it does not matter a tremendous amount what happened in between. >> Unless you happen to be the next person that gets to tweak the code. >> >> My main question in all of this was that the strict defniniton of unit >> testing is to test an object without all of its dependencies. Mock >> and stub objects seem to be the way to do that in other languages, but >> there had been very little discussion about doing this in ColdFusion >> (at least that I have seen). So, I wanted to see if and how people >> developed unit tests in ColdFusion. >> >> Thanks. >> >> ------------------------------------------------------------------------ >> >> Jeff D. Chastain wrote, On 12/22/2006 9:39 AM: >>> Sam, >>> >>> Yes, what I thought I said was that test drive development was to >>> write the test the object you are working on before you create that >>> object. The problem comes in when that object then depends upon >>> another object, etc. etc. >>> >>> If you check out the Martin Fowler link that Paul posted earlier, it >>> discusses very well two possible testing approaches ... state based >>> and interaction base. State based testing tests the entire depenendcy >>> tree in one test. Interaction based testing focuses only on testing >>> the specific object and its functionality. As stated in Wikipedia, >>> unit testing really follows Fowler's definition of interacton based >>> testing. >> >> I read it and I guess I'd consider myself more of a "state based tester" >> than interaction based. I have used stubs on occasion, and like he >> mentions (and as did I), there are typically few of them, so no need for >> mocks if you prefer to test that way. >> >>> >>> >>> This is the way I would prefer to test as I can quickly pin point >>> exactly where an issue is rather than having a dozen tests fail with >>> different errors because one object they all depened upon had an issue. >>> >> >> That's fine. I was simply telling the story of how I practice TDD. If >> you prefer to use mocks, I certainly have no problem with that! =) I >> also said I've yet to run into the potential problems you described (and >> apparently, a lot of people don't, otherwise I would assume everyone >> would be recommending interaction based testing all the time). But, >> also a lot of people prefer to use mocks. There are smart people on >> both "sides of the isle" so to speak. >> >> I haven't found that I often get a lot of tests failing because of one >> object they depend on being broken. I have had it happen, of course, >> but even when it does, I've never run into a problem figuring out who >> was the culprit. But, I've only been doing this for just under a year, >> and even if I had been doing it 10 years, I'd still think that other >> people have different experiences and I'd recommend they use the style >> that they find the most benefit in. >> >> >>> Mock objects (and stub objects) fit into the interaction based testing >>> model in that they allow you to stub out the interface of the >>> dependent object, making the assumption that it works as it should and >>> therefore focusing your testing on the single object at hand. Mock >>> objects take a stub object one step further and allow you to perform >>> additional assertions as to whether the depend object's interface is >>> being utilized correctly ... in other words, if function X was called >>> 3 times, was passed a single integer, and function Y was not called at >>> all. >> >> Yes, and now that I see Robert Blackburn has introduced mocks into >> CFUnit, I will be using them for stubs on my db calls for objects that >> use others who access the database. But, I expect I'll still be using >> state based testing, as like Martin Fowler said in that article, >> "Personally I've always been a state-based tester and thus far I don't >> see any reason to change. I don't see any compelling benefits for >> interaction based testing, and am concerned about the consequences of >> coupling tests to implementation. I also suffer from the disadvantage of >> not trying interaction based testing on anything more than toys." >> However, unlike him, I can see some "compelling benefits," at least for >> some cases that I would have liked to know how many times I've called >> methodX(). Though, I expect he is pragmatic and would use them if he >> found the need - I think he probably just meant something more like "not >> enough compelling benefits" or something of the sort. >> >>> >>> Testing objects and their dependencies in a "real world" scenario is >>> not a bad thing at all. In fact, it is called integration testing. I >>> just want to perform unit testing seperately from integration testing >>> so that when something crops up in my integration tests, I know that >>> the individual objects are doing what they are supposed to. >>> >> >> I thought I mentioned that it was called integration testing. In any >> case, I had meant to. But, I don't think it's useful in the development >> scenario to focus on what to call your tests, so I may very well have >> left it out. My apologies if I was confusing, or didn't get my idea >> across well. =) >> >> -Sam >> >> >>> -- Jeff >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Jeff Chastain wrote, On 12/21/2006 5:57 PM: >>>> There is always a need for both unit and integration testing, I just >>> don't >>>> like mixing them. Part of test driven development as I understand it >>> is to >>>> write the test for the object, then develop the object. >>> >>> >>> I'm not sure if you meant this or not, but for clarity's sake, I'll >>> describe it more like "write a test, then make that test pass." The way >>> I read what you said above, it sounded like "write all the tests, then >>> write the class." >>> >>>> How do you do this >>>> if you first have to write the dependent objects? >>> >>> You don't first have to write the dependent objects. When you find >>> yourself in need of one, then you create it. But you don't write the >>> whole thing. Just stub the method you think you need and have it return >>> what you are expecting - no real code. When you need real code, you >>> write the test for it first, as you always would. >>> >>>> There is a reason for the >>>> popularity of the mock and stub frameworks in other languages ... it >>> makes >>>> testing more precise. >>> >>> It can do that, yes. But, I'm not sure if that is why they are >>> popular. Several "thought leaders" in the Agile movement, as far as >>> I've been able to ascertain, either don't use them as extensively as >>> some people do (ie, perhaps they'll only mock database calls so the >>> tests can still run fast, or interaction with the file system, for >>> similar reasons), or promote them for use in projects that are are >>> already well established and have no tests. I haven't seen anyone >>> recommend them just for testing without dependencies. You still are >>> depending on the mock, after all. >>> >>>> Yes, you may never run into problems with a dependent >>>> object breaking the object you are testing, but I don't really see >>> that as a >>>> reason to allow the possibility. If it did happen, you could have >> a long >>>> dependency chain, part of which you might not be able to test (the >> event >>>> object in Mach-II for example) and debugging would be as difficult >> as it >>>> would be without unit tests. >>>> >>>> >>> >>> I'm not familiar with Mach-II, but I would have thought long dependency >>> chains are not generally advisable. And I'm certainly no expert on >>> that, so I could well be wrong. I can't remember a time when I've had >>> more than 4 or 5 in a chain though. In either case, it is important to >>> note that if they would be there without the mocks, they will be there >>> with the mocks too. And still further, if you had been doing what I >>> attempted to describe, all of it would be under test (that I can see - >>> but I may certainly have not explained it well enough, or I could be >>> missing something). The same cannot be said if you are only using >>> mocks, however. >>> >>> Can you provide an example, to help me see it? >>> >>> >>>> I have just seen a lot more posts recently about unit tests and TDD, >>> but I >>>> have not seen any examples short of very simple objects with no >>>> dependencies. >>>> >>>> >>> >>> Do you have an example you'd like to see in mind? I sat here thinking >>> of one for a couple of minutes, but I didn't find one in my head. But, >>> perhaps I can think of one later, if you don't have one in mind. >>> >>> -Sam >>> >>> >>> >>> >>> You are subscribed to cfcdev. To unsubscribe, please follow the >>> instructions at http://www.cfczone.org/listserv.cfm >>> >>> CFCDev is supported by: >>> Katapult Media, Inc. >>> We are cool code geeks looking for fun projects to rock! >>> www.katapultmedia.com >>> >>> An archive of the CFCDev list is available at >>> www.mail-archive.com/[email protected] >>> >>> >>> >>> You are subscribed to cfcdev. To unsubscribe, please follow the >>> instructions at http://www.cfczone.org/listserv.cfm >>> >>> CFCDev is supported by: >>> Katapult Media, Inc. >>> We are cool code geeks looking for fun projects to rock! >>> www.katapultmedia.com >>> >>> An archive of the CFCDev list is available at >>> www.mail-archive.com/[email protected] >> >> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> >> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
