Zucchini is an awesome cucumber-like visual testing framework for iOS. It works in a pretty awesome way by compiling CoffeeScript down to UIAutomation-compliant Javascript, and then running the test with Instruments.app's command-line tool.

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"]

  constructor: ->
    super 'post'

    extend @elements,
    'Post': -> view.navigationBars()["Post"].buttons()["Post"]

    extend @actions,
    'Type "([^"]*)"$': (text) ->
      messageArea = view.elements()['Message Text Area']
      messageArea.setValue text

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:

[myObj setValuesForKeysWithDictionary:jsonDict];

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

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:

require 'rubygems'
require 'xcodebuild'

XcodeBuild::Tasks::BuildTask.new

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
end

Then when you build using xcodebuild-rb, your output will look something like this:

Building target: ExampleProject (in ExampleProject.xcproject)
=============================================================

Configuration: Release
..............

Finished in 2.226883 seconds.
Build succeeded.

Read more about xcodebuild-rb on Github

xcodearchive

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.

Well, enter xcodearchive.

Unlike xcodebuild-rb, 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]
        --version
                                     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
        --developper_identity
    -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.