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/cfcdev@cfczone.org > > > > 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/cfcdev@cfczone.org 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/cfcdev@cfczone.org 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/cfcdev@cfczone.org
