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: Chris Hanson <email@hidden>
- Date: Wed, 1 Dec 2004 17:57:27 -0800
On Dec 1, 2004, at 2:28 PM, Jeff Laing wrote:
On Nov 30, 2004, at 2:51 PM, Jeff Laing wrote:
There is no auditabiliy whatsoever, and those of us who actually
*live*
by
code review will tell you that thats a recipe for disaster,
always, no exceptions.
You can use a unit testing framework to create unit tests that verify
your nib gets wired up properly on load. This is one way of making
sure that as you work, everything gets set up the way you want it (if
you write the tests first) and stays that way as you modify things.
Without wanting to sound too negative, especially since the initial
problem
seems to be with my machine and not with Interface Builder, you may
well
have missed the point.
I understood your point. I had a point of my own that I thought might
be of help to you (as well as other Cocoa developers following the
discussion): That you can automate this review by writing unit tests,
and that you can even automate the review in advance of implementing
the thing being reviewed.
All thats happened is that you've pushed the audit capability out into
the
test suite - I'd have to eyeball the test suite to ensure that it hit
every
nib connection that needed testing, and I don't have any provable way
of
knowing that my test coverage is complete. Whats out there in the nib
is
opaque, you can't easily (1) read it directly to determine what tests
are
necessary.
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.
Furthermore, if you develop your tests first, you aren't reading code
or a nibtool dump to determine what tests are necessary. 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".
In effect, you'd have to replicate in code all the connections you
expect to
be present in the nib, and if you've done that, why not just create
them
with code in the first place and be done with it?
Because I'd still want to test the connections if they're created in
code instead of a nib.
Unit testing and test-driven development aren't panaceas by any means.
But for things like this they're very useful.
-- Chris
_______________________________________________
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