Re: creating unit tests
Re: creating unit tests
- Subject: Re: creating unit tests
- From: Chris Hanson <email@hidden>
- Date: Sat, 7 Jul 2007 21:45:29 -0700
On Jul 7, 2007, at 8:25 PM, William Zumwalt wrote:
My program is in cocoa, yet there are several *.mm files where I
make calls
to a c++ *.dylib file. So when creating my test target, do I select
Cocoa >
Unit Test Bundle or Carbon > Unit Test Bundle? I've never used
carbon and I
know I'd like to write test for both my c++ and cocoa code.
You can just write OCUnit unit tests in Objective-C++ for your C++
code. Create a Cocoa Unit Test Bundle to put your tests in, and then
create a Cocoa Objective-C Test Case Class and add it to the bundle
target. Then just change its extension from ".m" to ".mm" and it'll
be built as Objective-C++ and you can test your C++ code from within
its test methods too.
I was thinking of creating one SenTestCase class and then creating
Suites
from within that, to organize all my tests from this one class.
While that's what one might do with JUnit, and it could work with
OCUnit, it's not really necessary. OCUnit will find all of the
subclasses of SenTestCase in your test bundle at runtime, and will
automatically construct a test suite from them.
And what
does Sen mean?
"Sen" is short for Sen:te, the company that originally wrote OCUnit
and made it available as Open Source under a BSD-style license. <http://www.sente.ch/software/ocunit/
>
Also, I did the tutorial for creating a unit test w/ the
TemperatureConverter project and at one point, the instructions said
I had
to drag *.m files from the Classes folder to my Test Cases folder
under
'Groups and Files' of XCode. Why did I have to do that when I want
to test
project code and leave it under my project folder (Classes)?
Unfortunately, the ADC unit testing tutorial was written using Xcode
2.0, whereas OCUnit was included as part of Xcode 2.1 and later.
(Please file a bug or provide documentation feedback via the links on
its page if you'd like to see it updated.) Back around the release of
Xcode 2.1, I put a bunch of material on my weblog about how to create
and debug tests for applications.
Xcode 2.1: Unit Testing Series
http://chanson.livejournal.com/119097.html
Xcode 2.1: Unit Testing Cocoa frameworks
http://chanson.livejournal.com/119303.html
Xcode 2.1: Debugging Cocoa framework unit tests
http://chanson.livejournal.com/119578.html
Xcode 2.1: Unit Testing Cocoa applications
http://chanson.livejournal.com/120263.html
Xcode 2.1: Debugging Cocoa application unit tests
http://chanson.livejournal.com/120740.html
Trust, but verify. (human interface unit tests)
http://chanson.livejournal.com/118380.html
Unit testing Cocoa user interfaces: Target-Action
http://chanson.livejournal.com/148204.html
You don't have to move the .m files from the Classes group (manila
folder) to the Test Cases group if you don't want to. I personally
like to keep my code very structured, such that all of the code for
each built product is in its own group; however, that's not necessary,
as long as the source files are properly referenced by their target's
Compile Sources build phase. Xcode's groups are purely
organizational, though they can be useful for specifying where files
are from since they can be added to a project relative to a path
associated with their enclosing group.
-- Chris
PS - If you or anyone else has any suggestions for improvements to the
unit testing functionality in Xcode or ways Cocoa can be made more
testable, please file enhancement requests at <http://bugreport.apple.com/
>. Thanks!
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden