BDD acts as a common language between business professionals and software developers to improve communication between the two. This increases the overall quality and efficiency of the development process. For example, it introduces more transparency into the process, since both parties can measure the project’s progress based on these test results. It also increases the involvement of the customer into the process, which leads to a product that is closer to the customers’ expectations and needs. Customers are happier when they see that their opinions and needs are respected and implemented into the product.

We currently work with Fitnesse in different projects to describe the customer’s acceptance criteria as detailed test cases. However Fitnesse uses a table structure in a wiki-like system to define tests. Many business professionals have experience with spreadsheets and can transform thoughts into tables. This can be confusing and hard to read sometimes. Since that leaves more room for different interpretations, misunderstandings are more likely to occur. We would like to use something more naturally understandable.

At eMundo, we are always looking for new technologies that can improve our workflows and increase the quality of our products. We believe Cucumber is a tool that can help fulfill the customer’s wishes by directly involving them in the testing process.

Cucumber is an alternative approach to implement BDD. It utilizes the Gherkin Syntax to specify the software’s behavior. Gherkin uses natural language to make it as easy as possible to understand while remaining machine-readable. This allows non-technical people to understand or even write such test without having to learn how to write actual code.

With Fitnesse, we need to translate every user story or technical description into a table format that can be processed by Fitnesse. This transformation reduces the readability of the description. Since Gherkin is a more human-readable language, this step could be eliminated by simply writing every user story or technical description in Gherkin. This could reduce the overhead and eliminate one step which could introduce errors. If done properly, this approach can transform every user story into a provable statement which can be automatically tested.

Our team noticed that our wiki and its rich text editor can lead to some problems, since making mistakes happen easily when it comes to technical names (names in CamelCase or names with dots in them) or URLs. Finding these flaws is not always trivial, since Fitnesse is hard to debug and not easily integrated into an existing development environment. Additionally, error messages can be misleading in some cases, which - sometimes - makes debugging and the development process strenuous. Since Cucumber is less complex and more straightforward, we believe that it can improve this situation.

Let’s go over a small example to test a tool which decides whether the current day is a Friday.

In Fitnesse, a test for this tool could look something like this:

The first two lines are a (non-formatted) description which is not necessary, but recommended for readability. The following table defines two tests for the days “Sunday” and “Friday” along with the expected answer. If we want to write the same test in Cucumber, it would look a little different:

The first two lines define the name and a description of this test (similar to the Fitnesse example). The following lines contain two scenarios, or test cases. As you can see, every test is just a simple sentence with the structure “given, when, then”. This is a more natural way of describing your tests, making them understandable even without any knowledge about software development and testing.

In case you like the more concise representation of Fitnesse tables better, you can combine multiple scenarios into a table, which looks fairly similar to the Fitnesse table.

Refer to the official 10 minute tutorial for a more detailed example of Cucumber.

Cucumber does not have a graphical interface. This is fine for software developers and automated testing, but it is not suitable for presenting tests to customers.

Fitnesse, on the other hand, comes with a simple web frontend, which allows our customers to inspect or alter tests and their results by themselves. Seeing a direct result of the altered tests makes the testing process clearer. This is particularly true for microservice architectures, where multiple middleware technologies (i. e. Kafka), databases (i. e. Cassandra) and different kinds of microservices (i. e. RESTful-API’s) work together. You can combine the UI of Fitnesse with your infrastructure by using a docker-compose setup. This complete setup can then be presented to the customer.

A customer can still gain an overview over their business logic - even in a microservice driven environment where implementation details are hidden. This is important, since we try to include our customers into the development process to ensure the product’s quality and customer satisfaction. That is why we use Fitnesse in many projects to implement acceptance testing.

We would like to have the benefits of both solutions: the Gherkin language for improving readability and a web interface for our customers to use. We did not find any solution that fit our requirements, therefore, we decided to write our own extension to achieve the following features:

We built a web frontend which can perform two tasks via a REST API.

The first job calls the API to compile a project in a given path. A project simply needs a Gradle job which runs the Cucumber tests. These tests produce a JSON file with the test results. We use these results to generate a HTML report using cucumber-reporting. The reports are then shown to the user.

The second task allows users to view and edit test files (.feature files) through the web interface. These text files contain the test definitions written in Gherkin (see above). This enables users to alter a test and review the result by rerunning the tests.

This prototype is not pretty, … yet :) - but we can get an idea of how this could look like. We will use this prototype to evaluate whether this is a better alternative to Fitnesse. If we decide to adopt this technology, we will add some features and a more shiny theme.