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: Jeff Laing <email@hidden>
- Date: Thu, 2 Dec 2004 13:26:45 +1100
> You're not just pushing the audit capability out to the test suite,
> you're also pushing the audit performance to the test suite. This
> means that instead of happening once, or piecemeal, a complete
> automated audit is happening every time you choose to build.
> This can be very helpful.
Just to ensure that I'm not appearing to be disparaging of this idea, all of
my projects already have this stuff in place - for every target in my app, I
have about ten "test feature x" sub-apps that do exactly this, and these
have been extremely valuable.
But they test the features I'm delivering, not the nuts and bolts that tie
the features together. To take it to an extreme, I could say that I need a
test that ensures that when I load "xxx.nib" that an instance of MyXXXClass
appears. But since my normal app will be doing that (since failure to
appear will cause assertions to fire), there seems little point.
Verifying that my menu items are connected to *some* target makes sense.
How I go about verifying that they are connected to the *right* target seems
to me that its going to take more code than its worth - keeping in mind that
worth is subjective.
> Instead
> you're using unit tests to specify what the connections should be.
> Robert C. "Uncle Bob" Martin calls his presentation on this
> "Testing is About Specification, Not Verification".
Ah, specification *before* development. Yes, that'd be nice, wouldn't it?
But sadly, only so many hours in the day.
Sorry, that comes across as sarcastic even to me, and its not really
intended that way. The big problem for me is that I'm *not* specifying it
first because literally I don't know what I'm doing till I've done it. I'm
laying out a user interface, checking what looks ok, adding the appropriate
methods to the class specs (as stubs), iterate until done.
I literally don't know what the best way to do it is till I'm doing it, so a
detailed spec is a likely OUTPUT of the prototyping process rather than an
INPUT. And the whole Interface Builder mindset, it seems to me, is that the
prototype is what you deploy.
> Because I'd still want to test the connections if they're created in
> code instead of a nib.
Would you seriously trust the code in your test suite any more than you
trust the code in the actual application? Why?
> Unit testing and test-driven development aren't panaceas by
> any means.
> But for things like this they're very useful.
100% agreed.
_______________________________________________
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