Re: Unit testing framework suggestions?
Re: Unit testing framework suggestions?
- Subject: Re: Unit testing framework suggestions?
- From: Martin Häcker <email@hidden>
- Date: Tue, 28 Sep 2004 16:33:58 +0200
Wait a second folks. I thought the discussion was about Unit Tests and
not about Acceptance Tests. Besides, if I cannot tests internals of a
class, who will give me the courage to refactor these internals? Often
these internals make more then 90% of the class. For example a
Telescope class might have a public method isTracking that simply
returns a BOOL ivar set by an internal method called 10x each second
that that corrects the geometry of the flex mirror, reads a frame from
the helper CCD, does some nasty image convolution, calls eigen vectors
based RMS routine and passes the result to a weighting function that
finally decides if the telescope is still tracking or the object was
lost. For a user of the class Telescopes these might be unimportant
details, but for me - the author of the class - these are the most
important methods, and I would like to be able to test them no matter
if someone have academic or other objections...
Now I'm not a heavywight in UnitTesting as some of you are, but I
always took such occasions as a sign that one class is doing too much
and that I should add a small class that encapsulates exactly these
internals. So the Telescope merely becomes some sort of Facade to the
real functionality.
Well, now that I think about it I'm a big fan of very little classes.
Though I'm still lacking lot's of experience.
After thinking some more: It seems to me that if you have test-classes
and source separated, it kind of enforces the use of many very small
classes. Integrating the Tests in the Classes on the other hand enables
them to do more - as it's still convenient to test.
Now I'm not sure which of the goals are more desirable to me or if
there is a middle ground to go with. But this seems to make the
engineering tradeoff more clear. Do you agree or am I overlooking
something?
BTW, a good suite of tests enables refactoring by first braking few
existing tests! If I make even a simple refactoring, say "rename
method", and my test bar is still green I know I am in trouble and I
do not have enough tests! When the tests are broken, I start fixing
them. When the bar is green again, I commit. If the bar stays red for
longer then an hour, I revert.
<g> When I rename a Method and a Test breaks I rather start swearing at
my stupid tools that weren't good enough to rename the method call in
the test too. </g>
Is there some sign on the horizon that we finally will be getting
SmallTalk or Eclipse Level Refactoring support? Right now the
Objective-C Tools are _very_ week. :(
cu Martin
_______________________________________________
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