dejalatele's personal blog

Throw catch in Ruby

2012-02-12T10:37:16Z

A few days ago I got stuck on the throw/catch concept in Ruby. The description on the Ruby documentation was not clear for me and I spend many hours trying to figure out how it works. If you are on one of those days and get also stuck on these concepts I'm going to try to show you how works through this example included on the Ruby documentation:

def routine(n)
puts n
throw :done if n<= 0
routine(n-1)
end

catch (:done) do
routine(3)
end

The above code prints out a sequence of numbers in reverse order, stopping the sequence when it reaches the zero. The way it stops the sequence is by the use of the throw statement. Catch defines a block that is labeled ("done" in the above example) and that is executed until a throw is encountered. Usually this throw statement is determined by a condition, in our example is "if n<= 0". Then, if the condition is not true it finishes the block where the thow is included, but if the condition is true it jumps out to the end of the of the active catch. In our example it finishes the script.

We can't have a throw statement with no catch block. Let's try the following variant

def routine(n)
puts n
throw :done if n<= 0
routine(n-1)
end

routine(3)

If you execute the code above you should see the following error

`throw': uncaught throw :done (ArgumentError)

because there is no active catch block, the throw was called but in the call stack there was not catch block labeled with a tag which matches the throw's tag (done in our example).

We can include more than one throw statement, here is an example

def routine(n)
puts n
throw :done unless n>2
throw :done if n>12
routine(n+1)
end

catch (:done) do
routine(3)
end

Finally, I recommend you to check this link and this link what were usefull for help me to understand this topic.

Launching the iPhone simulator using Apache Ant

2012-01-29T20:01:00Z

Here's the XML of an Apache Ant buildfile that allows the execution of an iPhone application on the iPhone simulator.

What you should see when you save this build file and run Ant is xcodebuilder will start to clean, build and install our application, and when xcodebuilder will finish the iPhone simulater will start automatically to run our application.

Some key points here are the following:
- The xcodebuild property is the path to the xcodebuilder executable.
- The sdk property should be the iOS version you want to run your application.
- The build_path property is the path where xcodebuilder will build and install the application. It could be any path. Notice that this property is passed into the macro responsible of the xcodebuilder execution.
- The application_path property is the path of the application inside the build path. It should be similar to the example above because xcodebuilder installs the applications on folder called Applications.
- The simulator_path property is the path of the simulator executable.
- You should specify the target of the application by the attribute target in all the xcodebuilder calls. Don't confuse the application target with the Ant targets.
- The macro xcodebuild contains the necessary code to call the xcodebuilder executable. Pay attention to the first attribute dir, it is the path to the source code of your application. Your can use the same attributes and arguments as in the example, but it is advisable to check man page of xcodebuilder for a better understanding of the meaning of each available arguments. Be careful with the order of the arguments inside the sequential Ant container because it executes the nested tasks in sequence, so if you wrongly modify the order of the arguments, xcodebuild will not run.
- Finally the iphone_simulator macro will run the simulator starting your application. The last argument (the ampersand) is passed with the only purpose of execute the simulator in background.

This build file can be used in various ways but the most useful could be the launch of automated tests.

Avoiding crashes

2012-01-13T18:41:29Z

When we doing test automation for iPhone or iPad using the UISpec framework we have to pay attention to the existence or not of the UI elements we interact with. If we try to touch a button, fill in a text field or perform any kind of interaction with an element and the element doesn't exist the Test application will crash and will stop the execution of the rest of specs. So, we have to check the existence of the element before try to interact with them. We can avoid the crash setting expectations before interact with the element.
Let's imagine a screen with two buttons and we want to touch the second one, the UIquery code of the button is

[[[app button] index:1] touch];

If this code is not correct or the button is no present on the screen the application which run the tests will crash, but if we set the expectation before the interaction

[expectThat([app button] index:1]) should:be(YES)];
[[[app button] index:1] touch];

as the expectation will not be satisfied the execution of this spec will finish at this point but it won't finish the execution of the whole test application. It will continue with the next spec.

A more elaborated implementation could be

BOOL existElement;

@try {
existElement = [[[[app button] index:1] should] exist];
}
@catch (NSException *exception) {
NSLog(@"EXCEPTION CAUSED BY: %@", [NSThread callStackSymbols]);
}
@finally {
[expectThat(existElement) should:be(YES)];
}