Tuesday, 21 September 2010

Slides from Skillsmatter talk

I did a talk at Skillsmatter with Gojko last night. We discussed dividing UI testing into three levels (expanding on Gojko's post with examples), in order to increase maintainability of the tests.

I have embedded the slides from the talk below.

The code associated with these slides can be downloaded from cuke4ninja.com. Unpack the zip, the project is in the java/WebNinja directory.

There was quite a bit of discussion after the talk. Most centered around the usefulness of implementing cucumber features after development. The general feeling seemed to be that this was not an ideal situation, since one of the primary benefits of using cucumber is the collaboration it enables between all members of the team.

There were also questions regarding where responsibility lay for different parts of the code. Should the developers write all the code, should the test team have some input? My view is, that like many team organisation issues, it depends on the people involved. Maybe you have testers who would relish doing some ruby code!

I was also asked to show cucumber giving pdf output. This didn't work at the time, because I hadn't installed the prawn gem, and since the pub beckoned I said I would post instructions later. Anyway, you need to install the prawn gem to get the pdf output, like so...

gem install prawn

.. or if you are using maven

   <gem>install prawn</gem

You will also need to use the
command line parameter the first time you run with maven.

Then when you run the tests use the -f[ormat] option to output to pdf, and specify the pdf file name.

--format pdf --out target/cucumber/result.pdf

These arguments can be configured in the pom file if you are using maven.

Thanks again to everyone who attended and to Skillsmatter for hosting the talk

Monday, 20 September 2010


I've been working with Gojko Adzic on a e-Book aimed at encouraging the use of Cucumber.

I'm pleased (and relieved) to say that version 1 of the book is now released. You can read the book online or download a pdf copy at cuke4ninja.com.

The initial seed for the book came from a series of articles posted on Gojko's Blog which gave an easy to follow tutorial on how to setup Cucumber for use with .NET projects. Though Cucumber is very well documented, it's broad support of many programming languages means that the documentation is distributed across many sites. We thought that a single document that detailed using Cucumber from first principles would be useful and help grow the Cucumber user base.

Our concern that the book may be too dry, coupled with an obsession with Ninjas and Chuck Norris jokes, resulted in our decision to give the book a Ninja theme, hence the title "The Secret Ninja Cucumber Scrolls".

This first version covers Cucumber from the ground up, including:
  • Overview of Cucumber, including a glossary of Cucumber and BDD terminology
  • Setting up Cucumber for Ruby, Java and .NET projects
  • Implementing basic features in all three languages
  • Effective test design 
  • Managing complex features efficiently. 

We are following an iterative release schedule. In the next release, we will be covering Cucumber web automation. This subject is also the topic for a talk I'm doing with Gojko at Skillsmatter tonight. I'll publish the slides from that talk tomorrow.

To download the PDF or read the e-Book online, point your browser to cuke4ninja.com. For news and updates, follow cuke4ninja.

Wednesday, 18 August 2010

Logging in Objective-C with Blocks

I've been learning Objective-C in my spare time, focusing on coding for iOS devices in particular. I tend to use debugging as the last resort when writing code, so logging is important. I have found the lack of decent logging in iOS to be a problem.

Being used to logging on java and .Net, NSLog does seem very primitive, and one solution does appear to be cocoalumberjack. I will be investigating this and doing a post soon.

In the mean time I am experimenting with using blocks to give me the flexibility I need as a minimum. This was partly motivated as a learning exercise for closures in Objective-C

The basic Logger header looks like this:
typedef enum {
kError = 0,
} TRLLogLevel;

@interface TRLLog : NSObject

+(void)logWithBlock:(NSString* (^)(void))block withLevel:(TRLLogLevel)level;

+(void)error:(NSString* (^)(void))block;
+(void)warn:(NSString* (^)(void))block;
+(void)info:(NSString* (^)(void))block;
+(void)debug:(NSString* (^)(void))block;

.. so a simple logger API then. The interesting part as far as I am concerned is this bit...
(NSString* (^)(void))

There is a full discussion on block syntax here, so I am not going to go into lots of detail. The example above is defining a block which takes no parameters and returns a string.

Inside the implementation, the block is used like a normal C function

+(void)logWithBlock:(NSString* (^)(void))block withLevel:(TRLLogLevel)level {

if (level > currentLogLevel)

NSString *msg = block();
[msg release];

This means that any expensive operations inside the block are not called if the log level is not met. To use the logger, the code looks like this

CGPoint point = [recogniser translationInView:self.view];

[TRLLog debug:^{
return [[NSString alloc]initWithFormat:@"handlePan [%f, %f]",point.x,point.y];

Note how because the block is a closure, it can use other variables that are in scope.