Unit Testing (was RE: Swapping isa's (was Re: Hex Edit controls ( resknife)))
Unit Testing (was RE: Swapping isa's (was Re: Hex Edit controls ( resknife)))
- Subject: Unit Testing (was RE: Swapping isa's (was Re: Hex Edit controls ( resknife)))
- From: Jeff Laing <email@hidden>
- Date: Fri, 3 Dec 2004 10:30:47 +1100
I
said:
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.
Georg said:
... and you shouldn't test things like where your menu item is, but what it
does when you hit it.
and this is where our disconnect is, I
feel. I don't care where the
menu item is, in terms of graphical position on paper. But if I am to test
that it is connected to the correct target, I must be able to locate it somehow,
presumably by searching the container it resides in for a corresponding menu
tag?
The ResKnife code from Uli and Nick does wonderful things with the
Paste submenu, but it is hard-coded to assume that the Paste function is in
"menu number 2" - it doesn't search for the menu by name, or tag, it just
uses the literal 2, which is clearly locked into what it "knows" the menubar
will look like. (It does search for the menu item correctly, as I recall,
just not the enclosing menu)
The problems I am experiencing are all of this ilk - mis-wiring in
the nib.
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];
This is the point where it falls down for me. I haven't got
the connection set up correctly yet between field and outlet (thats the mistake
I made), and as such, this returns a nil. But you didn't check that, you just
assumed (presumably) that when your test fails, you can work out from a red
light what the problem is, and for me this would involve stepping through with
the debugger.
Or have I missed exactly what you are
testing?
NSString *mf = [[lastModifiedDateField formatter]
dateFormat];
SEConfirmIsTrue([[creationDateField stringValue]
isEqualToString:[[theModel creationDate] descriptionWithCalendarFormat:cf]],
@"UI displays wrong creation
date string");
So, at this point, you seem to have hard-coded into your test the
desired format string? Why bother putting it in the nib then, why not just
have code force it to the desired value?
This seems to me to be the
equivalent of a "note to myself to set the format right" which I'll have to get
back to. It takes more code to check that the value is correct, than it would to
set it in the first place, surely?
I agree that the unit test doesn't end up in the
finished product, but I don't see this as improving productivity, at least in
the way that I've seen Interface Builder used.
As far as I can tell, what you've done could just as
easily be done with
-
(void)windowDidLoad // or whatever it
is that gets called when the window is loaded
#if defined(DEBUG)
assert
(creationDateField != null);
assert (lastModifiedDateField !=
null);
#endif
}
and its a lot closer to the original window handler
code, so its more likely to be kept up to date.
Its only down side that I can see is this doesn't
happen till runtime, so its not the same as your unit test that can be run
independently as the build cycle progresses. But
...
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.
... I don't understand how you can test it without creating the
nib - after all, its the nib
content you are testing. Yes, the test can be compiled first, but its code
like all other code and just because it compiles that doesn't mean its right and
what its testing is wrong.
Yes, you can eyeball the test which addresses my complaint about
not being able to eyeball the nib content (which you actually *can*, thanks to
nibtool -a).
_______________________________________________
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