Re: Re: Re: Unit testing and Xcode integration

FROM : Keith Ray
DATE : Mon Aug 14 19:22:41 2006

(1) I just tried to find OCUnit using spotlight in the finder and
failed to find it. Ditto for searching in Xcode. What's the header's
name?  (Its name should match what we call it.)

(2) In SenTestCase_Macros.h, macros starting with "should" are
deprecated, but the new trend (exemplified in "rSpec"
<http://rspec.rubyforge.org/> and BDD / Behavior Spec Driven Design)
is to use "should". Ironically, the original unit-testing framework in
Smalltalk that inspired JUnit, CppUnit, and OCUnit did use "should".

(3) I would like some "one-click" way to add the test framework to a
project, or to have the test framework already built-into the various
xcode project templates.

On 8/14/06, Christian Moen <christian.<email_removed>> wrote:
> On 8/14/06, Chris Hanson <<email_removed>> wrote:
> > On Aug 13, 2006, at 10:46 PM, Christian Moen wrote:
> >
> >
> > I don't intend for my responses to be perceived as defensive; I tend
> > to provide a lot of information as background that can sometimes look
> > more like rationale.  I genuinely want to know what would make the
> > experience of OCUnit within Xcode better from your -- and others'! --
> > perspective.
> >
> > "I was more happy with UnitKit" is a useful data point as far as it
> > goes, since it indicates that there's more work to do on the
> > integration.  However, it doesn't say what specifically you are
> > unhappy about with OCUnit as included in Xcode.  Specific information
> > about likes and dislikes is critical for coming up with concrete ways
> > to improve the experience.
>
> This is why I prefer UnitKit to OCUnit:
>
> 1) I really like UnitKit's Growl integration which OCUnit doesn't
> support, yet.  Just building my test bundle and getting a nicely
> formatted Growl message out-of-the-box with test results is very very
> nice.  OCUnit has build failed, which isn't nearly as cool, and you'll
> have to go into Build Results to see what failed when something
> failed.  It works okay, but it's not very elegant, in my opinion.
>
> 2) UnitKit's documentation was brilliant and got me started
> immediately.  Apple's documentation on OCUnit isn't nearly as good,
> yet.  Their documentation has a disclaimer that the documentation is
> prelimiry, but it doesn't seem to have been updated since Xcode 2.1
> (2005-06-06).  (I haven't read the documentation that Sen:Te ships
> with their OCUnit distribution.)
>
> 3) I don't like the inconsistency in naming with OCUnit as a package
> name and the ST prefix in the classes and macros.  If OCUnit is the
> package name, I'd expect class names, macros, etc. to also use an OC
> prefix.  I know a company names Sen:Te made this and gave it away for
> free, which is very nice of them, but I still don't think
> SenTestingKit isn't a great name for Xcode's "official" unit test
> package in filenames.  I think such a package should use a clear and
> consistent generic name -- in this case, OCUnit.
>
> My views are not new -- I generally agree very much with Mike Zornek
> (see http://mikezornek.com/archives/2005/09/27/ocunit_vs_unitkit.php),
> but I don't mind adding a description string to each assert, even
> though I think this is a bit superfluous since it's typically obvious
> from the test's method name.
>
> My two yen...
>
>
>
> Christian
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/keith.<email_removed>
>
> This email sent to keith.<email_removed>
>



--

C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>