Handling work-in-progress with Thucydides and JBehave using @pending and @wip tags

Thucydides version 0.9.268 has just been released, with a few very interesting new features. Thucydides is an open source reporting library that helps you write more effective BDD-style automated acceptance criteria, and generate richer test reports, requirements reports and living documentation. In this article, we will look at some of the new ways this version lets you handle work-in-progress or pending scenarios with Thucydides and JBehave. In JBehave, a scenario is considered passing if all of the step definitions are implemented, even if there is no code. This is because there is no obligation to use step libraries within the step definitions, though it is a good practice for more complex tests. Consider the following scenario: Scenario: Logging on via FacebookGiven Joe is a Frequent Flyer memberAnd Joe has registered online via FacebookWhen Joe logs on with a Facebook tokenThen he should be given access to the site When you execute this with no step definitions, it will be reported as Pending, as illustrated here: When you implement the steps, they will be considered successful unless an exception is thrown or a step is marked as pending. So the following will indeed pass:     @Given("$username has registered online via Facebook")    public void has_registered_via_facebook(String username) {} This is because there is no way to know that a step definition is empty - we can only know that no @Step methods were called, which does not necessarily mean that it is empty. You can make this a pending step by using the org.jbehave.core.annotations.Pending pending annotation, e.g:     @Pending    @Given("$username has registered online via Facebook")    public void has_registered_via_facebook(String username) {} JBehave and Thucydides will now report this scenario as pending, even though it has an "implemented" (albeit empty) step definition: This is also a good way to keep track of work if you are driving the code from the step definitions, as you can easily see which steps have been done at any point in time. The @ignore tag lets you skip a story during test execution, so that it does not appear in the reports. Meta:@ignoreScenario: Logging on via FacebookGiven Joe is a Frequent Flyer memberAnd Joe has registered online via FacebookWhen Joe logs on with a Facebook tokenThen he should be given access to the site If you want a scenario to appear in the report, but to mark it as 'pending' even if it fails, you can use the @pending tag directly within the story files, e.g. Meta:@pendingScenario: Logging on via FacebookGiven Joe is a Frequent Flyer memberAnd Joe has registered online via FacebookWhen Joe logs on with a Facebook tokenThen he should be given access to the siteScenario: Logging on via TwitterGiven Joe is a Frequent Flyer memberAnd Joe has registered online via FacebookWhen Joe logs on with a Facebook tokenThen he should be given access to the site or, for an individual scenario: Scenario: Logging on via FacebookMeta:@pendingGiven Joe is a Frequent Flyer memberAnd Joe has registered online via FacebookWhen Joe logs on with a Facebook tokenThen he should be given access to the site In this case, the entire scenario or story/feature will be reported as 'pending': You can also distinguish between work that hasn't been started yet and work that is in progress but not yet complete. The @skip or @wip tags will act like the @pending tag, but will report the scenario or story as "skipped". Scenario: Logging on via FacebookMeta:@wipGiven Joe is a Frequent Flyer memberAnd Joe has registered online via FacebookWhen Joe logs on with a Facebook tokenThen he should be given access to the site These will appear differently in the reports, as shown here:   This is a good way to identify what features are currently being worked on.  The following table summaries these options: What Where Outcome @Pending annotation Step definition code Individual step is flagged as 'pending' @pending tag Scenario metadata in the .story file The whole scenario is flagged as 'pending' @pending tag Story metadata in the .story file All the scenarios in the story file are flagged as 'pending' @skip or @wip tag Scenario metadata in the .story file The whole scenario is flagged as 'skipped' @skip or @wip tag Story metadata in the .story file All the scenarios in the story file are flagged as 'skipped' @ignore tag Story or scenario metadata in the .story file The story/scenario will not be executed and will not appear in the reports   John Ferguson Smart is a specialist in BDD, automated testing, and software life cycle development optimization, and author of BDD in Action and other books. John runsregular courses in Australia, London and Europe on related topics such as Agile Requirements Gathering, Behaviour Driven Development, Test Driven Development, andAutomated Acceptance Testing.

Posted by on 20 August 2014 | 10:36 am

And towards MVC 1.0 we go!

As part of the JavaEE 8 survey the question was asked if the community wanted a simple action-based MVC framework. Since the answer was a clear yes, we are now going working towards it. The MVC 1.0 JSR has been filed!

Posted by on 19 August 2014 | 7:54 am

BDD, automated acceptance tests and continuous delivery: dealing with scenarios that are 'work-in-progress'

One of the principle rules of Continuous Integration (and Continuous Delivery) is that you should never knowingly commit code that will break the build. When you practice test-driven development this is easy: you write a failing test (or, more precisely, a failing "executable specification"), make it pass, and then refactor as required. You only commit your code once you have refactored and ran all of your unit tests, to ensure that you haven't inadvertently broken anything elsewhere in the code. But acceptance tests take typically require a lot more code than unit tests, and take a lot longer to implement. If you start with a failing automated acceptance test, you may have a failing test for hours or even days. The general principle of CI still applies for automated acceptance tests - you should never knowingly commit code that breaks one on the build server. When people do this, it inevitably results in a continual stream of broken builds, which people ignore because it is considered the normal state of affairs. There is no easy way to know if a build is broken because of a regression, or because of an "in-progress" acceptance test. In these circumstances, CI has very little value. The status reporting becomes flawed. If "real" regression issues occur, they are detected and fixed more slowly. And any attempt at Continuous Delivery becomes impossible, since you can never reliably know when a build is ready to be released into production. Here are a few techniques that teams use to get around this problem: Tagging the acceptance tests One common approach used with tools like JBehave, Cucumber and SpecFlow is to tag the acceptance tests that are work in progress, and to configure the Continuous Integration build to only run the stories without the work-in-progress tag. For example, the following JBehave scenario uses the @wip tag to mark a scenario that is work-in-progress: User AuthenticationNarrative:In order to prevent unauthorized use of member pointsAs the system adminI want users to authenticate before they can access their accountMeta:@wipScenario: Successful authenticationGiven Jane is a registered Frequent FlyerWhen Jane authenticates with a valid email address and passwordThen Jane should be given access to her account This approach manages the living documentation well enough, but some other aspects need to be considered when it comes to actually implementing the features. Feature Branches Many teams use short-lived, preferably local, branches to develop new features. This is fast, easy and common practice for teams using git. The linux code base, for example, relies extensively on feature branching to develop and integrate new features. For teams still on centralized version control systems, it is a little more dissuasive, as branching and merging using tools like Subversion can be a painful process, and the concept of a local branch generally does not exist.. But can still be a viable option. The trick is not to let the branch live for too long (for example, more than a couple of days), because long-lived branches create a risk of integration issues down the track. At the risk of stating the obvious, feature branches should also include the corresponding automated tests, whether they be unit, integration, acceptance, or any other automated tests that will be run on the build server. These are written and run locally, alongside the application code, and merged back into the master branch along with the application code when the feature is finished. Incremental implementation Another, preferable, approach is to break down the new feature into small pieces that can be built and delivered incrementally. Even if short-lived feature branches are often used for this sort of work (simply because they are convenient, and make it easier to experiment safely), the increments are completed quickly, often within a few hours, before being merged back into the master. For bigger changes, you can use a slightly different approach. This usually involves building the new feature in isolation, maintaining the existing solution until you are ready to replace it completely. For example suppose you need to replace a payment processing module in your application. This is a large chunk of work, that you won't be able to do in one sitting. The first thing you do is to isolate the payment processing module, for example using an interface (if you are using a dependency injection framework such as Spring or Guice, this may already be done as part of your normal development work). You then build an alternative implementation of the module, according to the new or modified requirements, using TDD to drive the design and implementation. Your new acceptance tests use the new module; once these all pass, you are ready to replace the old implementation with the new. This approach is similar to the idea of "Feature Toggles" promoted by Martin Fowler, but much simpler to implement. It makes it feasible to work directly against the master branch, though it will not reduce the risk of integration issues if the development takes too long. Conclusion In both of these cases, the aim of the game is to never commit code that breaks a build, but at the same time to keep your code up to date with the latest changes in the code base.

Posted by on 17 August 2014 | 11:21 pm

Java Beans

Java Beans is a technology for Java and JavaFX. You can create cool applications with Java Beans.

Posted by on 12 August 2014 | 2:12 am

JavaFX Gui Design

JavaFX has nice GUI features. You can implement simple GUI features like textboxes or numbers and labels.

Posted by on 11 August 2014 | 11:51 pm

JavaFx Features

JavaFX has a lot of features to offer. With javaFX you can create small cool GUI applications.

Posted by on 11 August 2014 | 11:42 pm

Java 8

there is a new Java out there.

Posted by on 11 August 2014 | 7:06 pm

JavaFX

JavaFX is a great tool to play with. I will explain some more JavaFX in the future.

Posted by on 11 August 2014 | 6:48 pm

Physics A grat tool to play with

Physics are a great tool to play with? New ttechnologies, java, new playground. You can add new technology to an existibg kind of technology

Posted by on 11 August 2014 | 6:20 pm

NetBeans

Netbeans is an IDE to deploy Java and javaFX Applications.

Posted by on 11 August 2014 | 6:19 pm