Showing posts with label ruby. Show all posts
Showing posts with label ruby. Show all posts

Saturday, April 07, 2007

OCUnit test reports

Unit testing not only is quite usefull to make my code better but I also really like the visual feedback in the form of the junit generated html reports. The reports automatically generated by the Ant build script provide a nice overview what test cases work or don't work. More important, it shows me what I might have broken by adding a feature. The console results are just fine during development, the HTML reports are better suitable for publishing on the web for example.

These html reports are generated based on xml output from junit. This is all easy in an Ant based java project where tests are run using junit.

The problem is I mainly develop in Objective-C in which case I test using the OCUnit framework. The OCUnit framework nicely integrates with Xcode and displays failures the way Xcode displays compile errors. This is nice during development but pretty useless when builds are run automated on a remote machine.

So to publish test results from an automated xcode build I wrote a ruby script that transforms the console output from OCUnit to a junit compatible XML format. See the following Ant target how this works:

<target name="test" depends="build"
description="Builds the project, runs the unit tests, generates a report">

<exec executable="xcodebuild" dir="zip-framework" failonerror="false" outputproperty="xcodebuild.out">
<arg line="-target Test -configuration release build" />
</exec>

<mkdir dir="reports" />
<mkdir dir="reports/raw" />
<exec executable="OCUnitReport" errorproperty="report-error.out" inputstring="${xcodebuild.out}" searchpath="true" resolveexecutable="true">
<arg line="-d reports/raw" />
</exec>
<echo message="${report-error.out}" />

<mkdir dir="reports/html" />
<junitreport todir="reports">
<fileset dir="reports/raw">
<include name="TEST-*.xml" />
</fileset>
<report format="noframes" todir="reports/html" />
</junitreport>
</target>


The first exec task executes the OCUnit target called Test and saves the result in the xcodebuild.out property. The second exec task transforms this output to xml using the OCUnitReport script. Finally a junitreport task is used to transform this xml to a html report in the reports/html directory.

Why use Ant to build a Xcode project? For one, the only way for the automated build tool CruiseControl to build a Xcode project is to wrap the the command line tool xcodebuild in an exec task. Ant also contains a lot of useful build-in tasks like ftp which can be used for example to upload the build reports to an external server.

Download (ruby script, 5kb)

Thursday, December 07, 2006

RubyOSA on Rails

As posted before, I'm currently playing with with Ruby on Rails a lot. While doing so I discover more and more about the beauty of Ruby programming on Mac OS X (with or without rails). For example using the Ruby/Objective-C bridge it's possible to use any Cocoa Framework in a Ruby script. Even better, Apple seems to like Ruby and already made it clear Ruby on rails will be included in the next version of OS X.

So while searching for Ruby and OS X using google I found another useful gem: RubyOSA, a Ruby/AppleScript bridge. The bridge makes it possible to use any scriptable application as an object in your script.

The RubyOSA website gives a simple example of using Ruby to control iTunes. As an experiment I created a Rails application to do the same, but from a remote location. Not very useful on a live website because RubyOSA commands might take some time to execute. But combined with a wifi enabled phone or pda it results in a nice remote control for iTunes in a home network.

Friday, December 01, 2006

Ruby on Rails

About 2 weeks ago I started looking into Ruby on Rails. I've programmed using ruby before, and I installed a rails based blog before, but I never used rails to develop something myself. What I've seen so far really makes me think why I didn't start using Ruby on Rails before.

All the tools that come with Rails really make development much more easier than what I've used before. The scripts used to generate models, migrations and controllers from templates take away the need to repeat yourself with the most basic code.

More interesting is the tool called Capistrano. I just started using Capistrano only two weeks ago, but already I'm sold. Gone are the problems of releasing a new version and having a different version online then the one I'm working on. Since using Capistrano releasing websites to the web has become way more organized.

The current setup I'm using for the live server is an apache2 installation with 3 mongrel servers running in a cluster for each Rails application.

I develop the Rails application on my powerbook and test it using mongrel installed using Locomotive. The Rails installation is of course stored in a subversion repository. As soon as I think the current development version is ready for a release (feature complete and the tests show no errors occur) I tell Capistrano to deploy. A few seconds later my new version is online without me ever starting a ftp application. The database tables are updated automatically, files are checked out from subversion and all I have to do is sit and watch. And if somehow my unit tests didn't catch a bug, or something else has gone wrong, I'm back at the old version within 2 seconds. No more troubles with ftp, searching for the files that caused the error.

Because of all the information available on the internet you don't need a book nowadays to start programming a new language or to start learning a new framework. I usually find using Google to find API documentation is much faster then browsing a book. Tutorials on the web are usually more updated and provide useful user feedback in the comments. That's why you won't find much books at my place about programming.

I do buy books on occasion that provide me with information not available on the web. That's why I bought the book Rails Recipes. I read several positive reviews and after reading through the book myself I immediately felt like I would use it for each rails project. The book contains small 'recipes' usually not longer than 2 or 3 pages that provide snippets of code that show how an experienced Rails developer would solve a specific problem.




I own the book for two days now, and already I've learned more from it than from all the tutorials I've read. So if you know Rails already from the tutorials you've ready, but you're looking for more interesting pieces of code to read and use check out Rails Recipes.