While I have not worked on it in a few weeks, I would like to talk about Cukeness. Cukeness is an open-source project that I started right after attending Agile 2009. I actually started writing features/stories for the application in my Moleskin sketchbook on the plane flight home.
So what is Cukeness?
Cukeness aims to be a web-based user interface for Cucumber.
Wait. What is Cucumber?
Cucumber is a Behavior Driven Development tool that allows developers and product owners to have a conversation about how an application should work. This tool is great for the product owner, because the conversation is held using terms that she understands using plain English (or another natural language, like French or Italian). This tool is great for the developer, because the log of the conversation can be executed against the system under development to evaluate if it meets the product owner’s need.
Okay. And Behavior Driven Development is?
Behavior Driven Development, or just simply BDD, is an approach to software development that primarily focuses on delivering business value, not just technical value.
Got it. Now what does this conversation between product owner and developer look like?
The focal point of the conversation is the “feature”. Some approaches refer to this instead as a “story” and other approaches refer to this concept as a “use case”. The term you use does not matter. What does matter is that the developer and product owner work together to describe how the system is supposed to implement a particular feature. To do this, Cucumber provides the “scenario”. Each feature contains a set of scenarios. Each scenario describes, in detail, how the application is supposed to behave within the context of the feature that the scenario belongs to.
To convey this level of detail, scenarios are written with three kinds of sentences, each starting with either “Given”, “When” or “Then”. Given sentences are used to describe the steps that are taken to establish the scenario. When sentences are used to describe the actions that are performed. Then statements are used to describe the result that is expected from performing the action described in the When statement. These statements are written in a simple text file (example) with a name that ends with “.feature”.
Alright. How does Cucumber actually talk to the system under development?
Feature files (any file with a name ending with “.feature”) are given to the Cucumber command-line utility. Cucumber reads each sentences in the feature files and tries to find a corresponding “step definition”. Each step definition is responsible for talking to the system under development and performing the action that is described by the scenario sentence, or step.
Step definitions are written by the developer in a computer programming language. At this point, many different languages are supported, but ruby is the most common. Product owners should not have to worry about writing the step definitions. They only need to make sure that the step definitions get written.
So why does Cucumber need a user interface?
Perhaps it doesn’t. But not everyone is comfortable using a command-line interface, especially your typical product owner. At the moment, that means that developers become responsible for executing the feature files to determine if the system is behaving correctly. I would like to give this power to the product owner.
How does Cukeness let product owner execute the feature files?
Well, right now, Cukeness still needs a little bit of work, so instead I should talk about how Cukeness will do this.
Cukeness provides wiki-like editing capability for features and scenarios. This gives Cukeness users the ability to read existing features or scenarios and create new ones through a comfortable user interface.
Cukeness users also have the ability to execute the features and see the results of the execution. Users are able to execute all of the features at once, execute a single feature or execute a single scenario. Results are displayed by annotating each scenario sentence with the status that resulted by running the scenario sentence. Furthermore, sentences are colored coded to provide better visual feedback. Cukeness uses the same colors that the Cucumber command-line utility uses.
When can I use it?
Well, like I said, Cukeness still needs some work, and is not ready yet for public consumption. Not even as a beta. However, I encourage any developer that is interested to fork the source code on github and start playing around. I would really like to see someone contribute some patches to move the project further along.
I have been distracted by another side project that I am exploring, and as a result I have not worked on Cukeness in a few weeks. However, I am committed to seeing the project succeed.
What tools were used to develop Cukeness?
Cukeness is a ruby on rails based web application. Application behavior is described using feature files and are executed with cucumber. Tests are written with the rails unit testing framework, although I have been considering switching the rpsec for this.