Also, As their site describes further, the whole system works very much like Cucumber, the popular ruby/rails testing gem:
A Zucchini feature file consists of sections bound to contexts of different application screens. Every screen you proceed to needs to be backed up by a CoffeeScript class describing all UI elements you want Zucchini to interact with as well as custom actions you feel like performing on that screen.
Here's an example of one such class:
class PostScreen extends Screen
anchor: -> view.navigationBars()["Post"]
'Post': -> view.navigationBars()["Post"].buttons()["Post"]
'Type "([^"]*)"$': (text) ->
messageArea = view.elements()['Message Text Area']
Zucchini has an impressive set of features including:
- Using a natural language for interaction scenarios, such as
Then on the "Menu" screen:, etc.
- The ability test/compare against screenshots.
- Integration with Jenkins for full-on regression testing.
Zucchini only runs on Mac OS X 10.6 and 10.7 and requires XCode 4.2 as well as Ruby (at least 1.8.7).
The Zucchini site is full of really helpful links and installation instructions, so check it out, you can also find the Zucchini project on Github here.
Tom Harrington brings us another insanely valuable little bit of code that does some simple, yet awesome things with a parsed NSDictionary of JSON content:
- Provide a safe, generic alternative to Cocoa’s -setValuesForKeysWithDictionary: for use with NSManagedObject and its subclasses
- Handle cases where JSON data didn’t match up with what the managed objects expected. Getting a string where you expect a numeric value, or vice versa, for example, or getting a string representation of a date when you want a real NSDate object.
Basically Tom is examining his managed object's defined properties, and then looking into the NSDictionary he got when he parsed some JSON, and if any of the property key names exist in both structures, he sets the value.
The end result is being able to do something like this:
I love little tools and case studies like this as they always help to enlighten more of us to the awesomeness that is the Objective-C runtime.
Building iOS and Mac projects from the command-line could be a lot easier to work with.
Hopefully this post will give you a couple ways to make that happen.
I wanna talk about two different little tools that help ease the process of scripting or working with Xcode projects from the command line.
xcodebuild-rb is a neat little ruby gem that lets you create a
Rakefile inside the root of your Xcode project's folder that looks like this:
What does that get you?
Well, after creating that
Rakefile, running a quick
rake -T (which will list all available
rake tasks) will output something like this:
rake xcode:build # Builds the specified target(s).
rake xcode:clean # Cleans the build using the same build settings.
rake xcode:cleanbuild # Builds the specified target(s) from a clean slate.
One of the coolest features of
xcodebuild-rb is it's use of "formatters". One of my favorite formatters is called "progress". You can enable it like this:
XcodeBuild::Tasks::BuildTask.new do |t|
t.formatter = XcodeBuild::Formatters::ProgressFormatter.new
Then when you build using
xcodebuild-rb, your output will look something like this:
Building target: ExampleProject (in ExampleProject.xcproject)
Finished in 2.226883 seconds.
Read more about
xcodebuild-rb on Github
Apple ships Xcode with a command line tool called
xcodebuild, which as the name suggests, builds an Xcode project. One drawback about the built-in
xcodebuild tool is that it can't create
.ipa archive files.
xcodearchive isn't a ruby gem. It is just a
.rb file that you can put anywhere you'd like and run.
xcodearchive has a ton of great features, check out the USAGE output:
Usage: xcodearchive [OPTIONS]
Show version number
-v, --verbose Output more information
-g, --growl Show growl alerts to inform about progress of the build
-n, --do_not_keep_dsym_symbols Do not keep the dSYM symbols
-s, --show Show archive in Finder once created
-c, --clean Do a clean before building the Xcode project
-o, --ipa_export_path FOLDER Set the path of the folder where the ipa will be saved. Default is '~/Desktop'
-i DEVELOPPER_IDENTITY, Force the developper identity value
-p, --project PROJECT Specifiy xcode project
-h, --help Display this screen
Read more about
xcodearchive on Github
If you aren't already automating the tedious parts of your build and release processes, you are missing out. As any iOS developer knows, building and releasing can become some of the most monotonous and annoying parts of our jobs, hopefully these little tools will inspire you to start scripting your way to a smoother build/release cycle.