Introducing the Cukeness Project

I’ve had the idea for a new testing tool in the back of my head for years. I’ve been calling it Cukeness (more on that name later). I was actually working on the project when I first asked Andrea to join me on the Corgibytes journey. I did a horrible job of explaining to her why it needed to exist. So she said that I should put it on pause and focus on other things instead.

I kept hoping that someone else would come along and build something similar, but no one has. And we’ve encountered several clients over the last couple of years who would have greatly benefited from a system like Cukeness.

That’s why I’ve decided to revive this old idea and make it happen. This article is my attempt to teach you about Cukeness, describe my plans for it, and explain how you can get involved in its development.

What’s Cukeness?

Cukeness is going to be a tool to help software teams write executable specifications using the Gherkin language that was popularized by Cucumber. Team members will be able to collaboratively write specifications in a web browser and, from that same web browser, see the results of executing those specifications against the system that the software team is working in.

What’s an executable specification?

For decades, humans have been using spoken languages to describe how software systems should function. These descriptions have taken many different forms over the years. Requirements documents, design documents, and functional specifications is a very short list of the names that these documents have been given in the past.

The hope was that any software team would be able to read these spoken language descriptions and produce a system that functioned in a manner that was consistent with the documentation. In reality, that has proven to be incredibly difficult, in part because of the fact that a single sentence in a spoken language will often have multiple valid interpretations.

Executable specifications aim to solve this ambiguity by turning the human language words into instructions that are evaluated by a computer and turned into commands that are performed by the software system that’s being described in the specification. If all of the executable specifications run without detecting any errors, then the software system can be thought up as meeting the demands required by the specifications. If someone determines that the system should still behave differently, then the executable specifications need to be adjusted to reflect this change.

What problems will it solve?

Cukeness is designed to solve 3 distinct problems that most software teams encounter when they are trying to introduce or expand their use of executable specifications. All of these problems stem from the reality that on any software team, there are different team members with varying degrees of technical proficiency with the tools which will allow the team to take full advantage of executable specifications. Teaching all of the team members to use each of the required tools is not the best use of the team’s time. Their time is better spent focusing on improving their software system.

Storage - Where do I put the specifications?

Any team that starts creating a library of executable specifications has to figure out where they should store their specifications. And that’s just the beginning of the storage discussion. How is the team going to tell which set of specifications is the “official” set that should be used to determine if the software system is functioning correctly?

I encourage teams to keep their specifications in a source control system, such as Git. This creates a very durable record of how the specifications have changed over time, and source control systems have very clear ways of specifying which version of the specifications should be considered official. However, working with a source control system such as Git can be really challenging for a team’s less technical members. Should I use a desktop app or a command line tool? Are there other team members who can help me if I get stuck? How will I know if I’ve saved my changes correctly?

I think it’s best to shift this burden off to Cukeness. Let it keep the specifications in a source control system for you. That way, your team members can create and edit and organize specifications in a way that makes sense to them without having to worry about the low-level details of how the specifications are being stored.

The current plan is to have Cukeness to store specifications in Git, but present a user interface that hides a bunch of the complexities of working with Git.

Editing - How do I make changes to the specifications?

Another difficulty that teams quickly run into is that of how the specifications should be edited. What program needs to be used to do the editing? A text editor that supports editing files in plain text is required. A programmer’s text editor that has support for syntax highlighting, snippet expansion, and keyword suggestions is best. This is not the kind of tooling that less technical team members are typically familiar working with.

Most less technical team members are intimidated by these tools. They would feel much more comfortable with an editing experience that’s similar to a modern word processor, such as Microsoft’s Word, Apple’s Pages, or Google’s Docs. The trouble with those applications is that it’s really easy for special formatting characters to interfere with the tools that execute the specifications.

The goal is for Cukeness to provide an editing experience that most team members will be comfortable using while ensuring that the specifications won’t cause any issues when it’s time to execute them.

Execution - How do I run the specifications?

The magic of executable specifications is that they are executable. However, the tools that are used to execute these specifications require a fair bit of setup, don’t always produce output that’s easy to understand, and often require being able to build the software system from its source code.

The goal is for Cukeness to provide a “click the play button” experience for running the specifications. Any output from running the specification will be shown in the same user interface that’s used to make changes to a specification. Meaning that if you make a mistake in what you wrote, you can run your specification, see the results and then quickly make the required adjustment, without having to switch contexts from one tool to the other.

To implement this, we’re planning on running the cucumber from the command line tool behind the scenes and taking advantage of the cucumber wire protocol to communicate with the software system that’s being evaluated for correctness. This will require a little bit of setup for the more technical team members, but once that’s done, the rest of the Cukeness infrastructure will make it very easy for the less technical team members to take full advantage of executable specifications.

This sounds great! When can I use it?

Happy to hear that you’re excited. Before you can use Cukeness, it has to be built. The Corgibytes team has decided to build Cukeness as an open source project. There’s not enough built yet for people to use. We could use a hand with that if you’re able to help.

How can I help?

You can get involved in the project a couple of different ways. You can visit the Cukeness project on GitHub and dive right in if you’re used to helping out on open source projects. Another way that you can help is by joining one of our virtual Mob Programming Sessions. That will give you a chance to work with M. Scott Ford and other Corgibytes team members as they build Cukeness and make it a reality.

Are you going to make any money off this?

Open source sustainability is something that we’ve considered from the very start of this project. Our current plan is to fund the project by charging a small fee to teams that want to use our hosted version of the application. Teams that want to install Cukeness on their own hardware can do so without having to pay anything. For teams that want to run Cukeness behind their firewall, but don’t want to go through the hassle of setting up an environment to run it, we’ll sell a commercially supported enterprise version of the application that can be easily installed on premises.

If you’re interested in either the hosted version or the enterprise version of the application, please get in touch. We’d love to have an early alpha tester or two who can help us work out any kinks. Knowing that there’s interest will also help us prioritize our efforts in this area.

What’s up with the name?

The name Cukeness is inspired by an older tool that tackles the executable specification problem in a different way. That project was called FitNesse. It was based on the Fit: Framework for Integrated Tests, a testing framework built around the concept of a spreadsheet or a columnar set of data as inputs and outputs to the program being tested. The Fit framework was created by Ward Cunningham, who is also credited with inventing the Wiki. FitNesse was conceived of as a combining of the power of the Wiki with the power of the Fit framework. Users were able to create Fit-based tests by creating new pages in a wiki. Furthermore, users were able to execute those tests without leaving the web browser, which also showed the results of running each test within that same browser.

Anything else?

Nope, that’s all that we have to share for now. Hope to see you at a mob session or collaborating on GitHub.