BDD – Best Practices for BDD and Cucumber in Java

bddcucumberjavaseleniumunit testing

I'm trying to understand some best practices when it comes to BDD and Cucumber. I've only recently started to use it,
and the first feature I have written a test for is testing a search feature, more specifically how a Repository layer
integrates with a JPA EntityManager that has been injected using the @PersistenceContext annotation. It does this by
creating an EJBContainer using the GlassFish embedded maven dependency and initialising the persistence layer this way.
It works so I'm fairly happy with that.

Now I'm at the stage where I want to start using Selenium with Cucumber to test the search feature of the JSF page. Which
I'm assuming I'll be able to check the contents of a HTML table after the search has been submitted.

Is it possible to use the same feature file with a different steps class that does Selenium testing? Is this a good practice?
At the moment none of this Cucumber stuff feels like unit testing, it all feels like Integration testing!

What I have in mind is something like the following organisation

test
    |
    java
    |   |
    |   feature
    |       |
    |       web
    |       |  |
    |       |  user
    |       |      UserSearchWebSteps
    |       |      UserAddWebSteps
    |       |      UserDeleteWebSteps
    |       |      UserWebTest
    |       db
    |          |
    |          user
    |              UserSearchDBSteps
    |              UserAddDBSteps
    |              UserDeleteDBSteps
    |              UserDBTest
    resources
        |
        feature
            |
            user
                search_users.feature
                add_user.feature
                delete_user.feature

So the steps would be organised at the level of web or db, and then in this example each user step is under that. With
a corresponding runner test class that runs all those steps

And as both the web and db levels expect the same results I'd have shared feature files.

The UserXXXTest would then specify in it's cucumber options where to find the feature file, and because the steps for web
and db are separated at the pacakge level having a step method with the same regexp shouldn't be an issue.

@RunWith(Cucumber.class)
@CucumberOptions(features =
{
    "src/test/resources/feature/user"
})
public class UserDBTest
{

}

Best Answer

Traditionally in BDD we'd start with the outside and move in, so we'd have a web page, then from there move to the actual DB connections until the scenario worked with the web page.

However, your question about whether you can use the same feature file with different steps at different levels is appropriate and applicable.

I don't think at the moment that Cucumber actually does this. Behat for PHP does. Konstantin Kudryashov's post on how to model the domain using the same end-to-end scenarios that work through the web layer may give you some ideas about how to do this kind of thing well (short version: remember to make your scenarios declarative!)

If you wanted to do it in Cucumber, I think it might be possible if you used symbolic links to mirror the feature files that you wanted to run in both places? You'll need some jiggery-pokery to get it to work. But... the theory is very sound, and Konstantin who's a well-respected BDD community member has been exploring this space for a while.

Even at lower levels, though, it wouldn't be a unit test, but an integration test.

It is possible to use BDD at a unit level (it started there, after all) but you'd probably want to use something like RSpec rather than the heavier-weight system-level frameworks.

Related Solutions

At which architecture level are you running BDD tests (e.g. Cucumber)

It is important to keep the testing triangle in mind when creating tests:

alt text

This means you should create many more tests at the lower levels of the triangle, and spend less time higher up. It is more costly to maintain end-to-end tests than unit tests.

Ruby on Rails Testing – Are RSpec and Cucumber Worth It?

My 'ah-ha!' moments about testing in Ruby and Rails came when I really sat down and read the definitive resources on the subject, the Rspec and Cucumber books. I shared your initial disdain of Cucumber, but then I realized that I was looking at the picture from quite the wrong angle.

Basically, Cucumber is about BDD (behaviour driven development) - you use Cucumber to plan your features, what you're going to work on next. Hmm, next you want users to be able to promote posts on a forum or something (to steal an example ;)) So you write something simple.

Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.

Note that there's no references to anything code related in there pretty much. That comes in your steps. When you refactor your code, you might have to change your step definitions, but the behaviour (your feature) will never need to change.

Now every time you run your Cucumber feature, you'll pretty much be led through how to test the feature using TDD (test driven development). This is done at a lower level using RSpec.

First run - my first step definition is undefined. Copy the block to define it in say user_steps.rb or even session_steps.rb because it relates to users and their sessions. Now, how do you define that a user is logged in? You can take them through the login process.

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

Should be all happy. Second step.

Given /^I can see the post "(.+)"$/ do |name|
  visit post_path(Post.find_by_name(name))
end

Again pretty easy. Note that if we totally redo our login process, or how our posts are defined and shown, we don't have to change the behaviour. Third step.

When /^I vote the post up$/ do
  pending 
end

Here's where you're starting to talk about new functionality, but you don't quite know how it's going to work yet. How do you vote a post up? You might click an image of a +1 or something, which does an ajax post to a controller, which returns JSON, or some such. So now you can move into pure Rspec testing.

Test your view to make sure the +1 image is displayed,
Test your controller that it behaves correctly when it receives a given ajax request of the right format (both the happy and unhappy paths - what if an invalid post ID is received? What happens if the user has used up their 25 upvotes in a day? Does it increment the number of votes correctly?)
Test your javascript that it responds correctly when given a blob of JSON in the right format (does it update the +1 image to show it's been used? (thinking of Google+ here...) Does it show the thank you message? etc.)

All of this doesn't affect the behaviour - but when you're finished dealing with the lower level testing, it will be trivial to fill in the step definition for how to vote a post up. It might be as simple as click_link '+1'. And the rest of the steps are testing results, which again should be straightforward to do. And when you're done, then you know your feature is complete and finished. If the necessary behaviour changes, you can tweak your feature, else you can tweak your implementation code in perfect safety.

I hope this makes sense. It's all been off the top of my head, but I think it demonstrates the difference between BDD and TDD, and why Cucumber and RSpec serve different needs.

Best Answer

Related Solutions

At which architecture level are you running BDD tests (e.g. Cucumber)

Ruby on Rails Testing – Are RSpec and Cucumber Worth It?

Related Topic