-
Notifications
You must be signed in to change notification settings - Fork 140
Getting started
First, follow the Installation instructions if you haven't already done so.
Once Cedar is set up correctly, specs added to your test target should run when you run your app's tests using ⌘ + U (or Product > Test).
When your run your specs, you should see output in the console or iOS simulator indicating which specs have passed and which have failed.
At this point, you can add your own specs to your new target. Check out Writing Specs for more details on what is possible.
Installation of code snippets is described on the installation page. These are installed into
~/Library/Developer/XCode/UserData/CodeSnippets for Xcode, and ~/Library/Preferences/appCode20/templates for AppCode.
Here's a list of the completion shortcuts and what they do:
| Shortcut | Yields... |
|---|---|
| cdesc | describe |
| ccont | context |
| cit | example (it with block) |
| cbef | beforeEach |
| caft | afterEach |
| csubj | subjectAction |
| cshare | sharedExamplesFor |
| cbl | itShouldBehaveLike |
| cblcont | itShouldBehaveLike (with additional context) |
| cpend | pending example (it with PENDING) |
| PENDING | expands PENDING into an empty block |
All of the above constructs are described in Writing Specs.
You can run your specs on the command line with Xcode's command line tool, xcodebuild. This is the same as if you were running XCTest/OCUnit tests. Here's an example showing how you can run iOS specs against an iPhone 5s simulator running iOS 8.1:
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -destination platform='iOS Simulator',OS=8.1,name='iPhone 5s' clean test
And here's another example demonstrating how you can run OS X specs:
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp clean test
For more details usage information, see the xcodebuild man page.
If you're looking for a more robust solution to this problem, we encourage you to check out the Thrust gem.
Sometimes when debugging or developing a new feature it is useful to run only a subset of your tests. That can be achieved by marking any number of examples with an 'f'. You can use fit, fdescribe and fcontext like this:
fit(@"should do something eventually", ^{
// ...
});If you're running Cedar in standalone mode, then you will get additional feedback about tests that are skipped:
-
If your test suite has at least one focused example, all focused examples will run and non-focused examples will be skipped and reported as such (shown as '>' in default reporter output).
-
It might not be immediately obvious why the test runner always returns a non-zero exit code when a test suite contains at least one focused example. That was done to make CI fail if someone accidentally forgets to unfocus focused examples before committing and pushing.
-
The CedarShortcuts plugin also provides keyboard shortcuts for focusing on specs under editor cursor.