Re: Swapping isa's (was Re: Hex Edit controls (resknife))
Re: Swapping isa's (was Re: Hex Edit controls (resknife))
- Subject: Re: Swapping isa's (was Re: Hex Edit controls (resknife))
- From: Georg Tuparev <email@hidden>
- Date: Thu, 2 Dec 2004 09:34:48 +0100
On Dec 2, 2004, at 4:00 AM, Jeff Laing wrote:
I'm talking about writing a few
simple tests for the direction you're thinking about taking, writing
some code (or wiring up a nib) that satisfies those tests, and then
refactoring. And then repeating that process.
Understood, except that I'm using Interface Builder to work out what
direction I'm taking.
This is fine, and we all do this. But you should not forget that the net effect of this is equivalent of writing a program tha instantiates objects, configures them, and stores them for later use. If you think of IB in this way, you will come to the realization that it is very reasonable thing to write unit tests.
I don't pre-visualise it in my head, I just sling
widgets onto e-paper and see what sticks. As such, while I could theorize
"there should be a frammitz function somewhere", I really can't tell till
the user interface is designed whether it'll be a button, or a menu item, or
both and thus I can't code a test in advance.
... and you shouldn't test things like where your menu item is, but what it does when you hit it.
Below is a typical example of a unit test that tests UI behavior (I wrote this just a minute ago, and when the tests turned green, I started reading emails). As you can see, I do not care if the creationDateField is 17 pixels to the left of bum-bam box, but I care if it displays the right date value (properly formated - this means also properly localized).
- (void)testDocumentDates {
TTSciNetDocument *document = [self document];
TTSciNetModel *theModel = [document sciNetModel];
NSString *cf = [[creationDateField formatter] dateFormat];
NSString *mf = [[lastModifiedDateField formatter] dateFormat];
SEConfirmIsTrue([[creationDateField stringValue] isEqualToString:[[theModel creationDate] descriptionWithCalendarFormat:cf]],
@"UI displays wrong creation date string");
SEConfirmIsTrue([[lastModifiedDateField stringValue] isEqualToString:[[theModel lastModifiedDate] descriptionWithCalendarFormat:mf]],
@"UI displays wrong last modified date string");
}
The really important thing here is that this test was created before the nib, and before the source code that creates the dates, etc. This is what Chris describes as "Testing is About Specification, Not Verification"! You create Unit Tests FIRST to design your functionality, to document it, and of course to test it. BTW, I run all unit tests at least few times every hour, and they all have to pass before I move on.
Another remark. What I described above might seam slow. It is not! I hardly ever use debugger, and what is even more important, when I am asked to make a major change, I feel confident I can do it in short time, because my Unit Test will tell me if I brake any existing functionality. So, your boss will be also very happy if you adopt this technique...
have fun
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden