There are two varieties of tests that can be run on the OCUnit platform - so called "application" tests, and so-called "logic" tests.
Only "application" tests allow you to exercise UIViewControllers, UIViews and so forth. If you specified "create test target" when you created the project, it will use the "application" style. Otherwise adding a teset target later, by default, uses the "logic" style. To covert an existing test target to use "application" tests, TwoBit Labs have a nice: guide
Another way to exercise code all the way up to the view controller and views is to use the Cedar BDD test framework. Cedar tests are run inside of an iOS application, so besides being able to test ViewControllers and Views, its also possible to test on either device or simulator.
UIAutomation allows the execution of automated functional tests, by driving the UI itself (as opposed to exercising UI code). The problem I have with UIAutomation is that, as far as I know, its not possible to execute it from the cmd-line, making it hard to include in an automated test suite - one that would be run by a continuous integration server. . . . someone might come up with a work-around for this using Automator.app or similar, but so far nobody has.
Calabash is another great UI testing framework, and can be run from the cmd-line, so doesn't suffer from the limitations I described above, wrt UIAutomation.
Bear in mind that automated functional testing, and testing UIViewControllers and Views at the code-level are two very different things. The latter certainly has value, and simply requires setting up the bundle loaders correctly.
Update: With recent versions of Xcode 5+, application-style tests are the default.