Database Reference
In-Depth Information
Once you have a testing target, you can immediately try running it, since the default
template creates a single unit test file with a single failing test case. You'll eventually
want to have multiple files of tests; you can create more by dropping new “Objective-
C test case class” files into the unit test target.
There are a few things to point out immediately. Firstly, you need to make sure that
the testing target has access to all the classes, frameworks, and resources that the test
cases will need to run. You can set them up in the Build Phases tab of the target info
( Figure 5-2 ).
Figure 5-2. Adding dependencies to a test target
This used to be a lot more of a pain in the butt than it is now. Until recently, OCUnit
tests ran at compile time, and therefore couldn't make use of things in the framework
libraries, or any class in your code that included them. You had to carefully manage
which files went into which target, or your unit test target wouldn't compile.
Well, all that has changed. You can now make your whole honking application a de-
pendency of your unit test target, and have access to anything in it, as we'll see later.
But for the moment, just know that if your test target sets a target dependency on your
application, you should be all set.
Once you have the test target all set up, it's time to write some unit tests. Remember,
unit tests are intended to test the functionality in a single class, and purists insist on
using techniques like dependency injection and mock classes to isolate logic down to
 
Search WWH ::




Custom Search