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 18:42:44 -0800
On Dec 1, 2004, at 6:26 PM, Jeff Laing wrote:
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.
In agile methodology terms, these would be acceptance tests. And
they're very useful too, but not really the same thing as unit tests.
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.
Actually, this is exactly the kind of thing I'm talking about testing.
It turns out that it's quite easy and valuable to test this kind of
thing, and to have the tests run every time you build as part of the
build process (rather than as an extra step).
If you use a unit testing framework, rather than create a separate
sub-app for each test, it removes a lot of the tedium from it.
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.
Actually, it doesn't have to be. I'm not talking about writing a
detailed specification and then writing a detailed test suite from that
specification and then writing code. 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.
It's just about as straightforward as writing the code straight, with
the added bonus that you can know if you've broken some other part of
your code almost immediately, and you can be sure you've accomplished
all (rather than most) of what you set out to because your tests pass.
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?
Because I'd be writing the test code first, and the test code is almost
always extremely straightforward. Do something, then verify the result
or the state change. Do something else, then verify the result or the
state change. This is easier to get right and have high confidence in
than some application logic.
http://c2.com/cgi-bin/wiki?UnitTest
The above is sort of the canonical unit testing page on the c2 wiki.
Lots of good discussion on this type of issue there.
-- 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