Cucumber Web Bridge (CWB) is a framework for automatic testing of web interfaces. Currently it supports 2 type of web interfaces: your classic HTML based website and REST based webservices.
It's a text-driven framework, meaning you define the tests you want to execute in a simple plain text format instead of in a scripting or programming language directly. This is where Cucumber comes in. According to their website “Cucumber lets software development teams describe how software should behave in plain text”. It provides a plain text DSL called Gherkin to do this and has libraries in many different programming languages that help you convert the plain text scenarios into runnable test code.
CWB is built on top of Cucumber, using the Gherkin DSL as the driver for the tests. A test scenario in Gherkin is made up of several steps that do one or more actions. CWB comes with a default set of steps that allow you to manipulate webpages. That is in fact the core of CWB: a framework bringing you all the facilities and steps to quickly get you started testing web interfaces using Cucumber.
Who is it for?
CWB is meant for developers and product owners alike. Anyone with some technical background and a good idea about writing UI test scenario's can put it too good use.
What exactly can I test with CWB?
CWB is all about testing web interfaces:
Execute actions on a website - clicking buttons, following links - and verifying that certain content is displayed. Submitting a form an checking that certain fields are highlighted. Or more complex flows like creating a blog article and verifying it is displayed on all the pages you published it to. See the Language Reference page.
JSON REST web services
Perform POST, GET, PUT actions to web services. Create request data using YAML and verify or query the response you get back. See the REST steps language reference.
How much does it cost?
Nothing. CWB is entirely free and open source (and will remain so). It is built on top of other open source frameworks like Cucumber Java, Spring and SAHI.
Apart from command-line, it's perfectly possible to ConsoleRunner from inside a unit test. This means you could have different JUnit tests (or some other framework) that run different cucumber features in parallel.
You can configure all settings and pass in system properties. Inside your unit test you can only assert the exit code of the ConsoleRunner (only 0 is ok), but all logs and reports will still be written to the output directory specified.…
We've added a new option to the ConsoleRunner that allows you to specify entire directories of features that should be run in order. This can help improve performance and reduce configuration overhead for a large test suite.
In this tutorial I will show you how to use Cucumber and CWB REST to test a Spring Boot microservice. Starting from a Spring Boot application using an embedded Tomcat, we will first setup the CWB integration and write a simple feature. The feature will connect to the actual running webserver and execute its scenario's.…
After using a SNAPSHOT for almost 2 years, we have finally gotten around to creating a first public release of Cucumber Web Bridge. Version 1.1.0.RELEASE is directly available on Maven central, no longer requiring you to use the Foreach repository.
The current snapshot of CWB has been updated and includes some new steps that can be used for checking of HTML attributes and CSS classes.
An element can now be checked for the presence or absence of attributes, along with the set attribute value. Additional steps are included for CSS class checking, that allow you to verify the presence of class names regardless of their order.
Users running CWB scenarios directly from IntelliJ 14.1.3 or higher have reported that execution fails with Exception in thread "main" java.lang.NoClassDefFoundError: org/springframework/transaction/TransactionDefinition.
The cause is incorrect detection of the Glue property, for some reason the package cucumber.api.spring is added incorrectly.
The solution is to manually define the glue (eg com.foreach.cuke) in the default run configuration.…
Even when automating UI tests, it is important to keep your scenarios as readable as possible, or you threaten to lose all benefits from a plain-text approach. In this post I’ll give you some tips that can help you with the basics.
In this post I'll explain how you can use the new ConsoleRunner to execute CWB tests in parallel and have failed tests automatically retried. This aids you in running tests faster and can be especially helpful when suffering from random failing SAHI tests.
As of now we are switching to using a custom SAHI build for CWB. The first version is based on SAHI OS 5 and adds some customizations. It's advised that all projects switch to the new build as soon as possible.
New step: exists
Analog to the visible/not visible step, there is a new step added for exists/does not exist.
Where the visible step also perform a css check (except for visibility hidden and display none), the new step only checks if the elements are available in the DOM structure.
New step: wait until X
Just a pointer for Cucumber tests:
Avoid the i should see “TEXT” step, it checks only if a certain string is found in document.body. It is easy but it is not reliable to check if this text is really visible. Choose to see if a specific element is visible or contains a certain text.…