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. "The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing provides a strict, written contract that the piece of code must satisfy." 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. 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. 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. -- 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]
