Cucumber Step Definition for "Given That I'm Logged In"

Cucumber step definition for Given that I'm logged in

here is how I do it.

Given /^I have one\s+user "([^\"]*)" with email "([^\"]*)" and password "([^\"]*)"$/ do |username,email, password|
@user = User.new(:email => email,
:username=>username,
:password => password,
:password_confirmation => password)
@user.save!
end

Given /^I am an authenticated user$/ do
name = 'exmample'
email = 'example@example.com'
password = 'secret!'

Given %{I have one user "#{name}" with email "#{email}" and password "#{password}"}
And %{I go to the user login page}
And %{I fill in "user_username" with "#{name}"}
And %{I fill in "user_password" with "#{password}"}
And %{I press "Sign in"}
end

The reason I do it this way, is that I run through the entire stack and set the environment up the way a normal user would...

Do you do this in every step definition ? Given that I am logged in

I typically do, yes. For me, it seems clearer when you're reading the tests and seeing the output in the console.

If you don't want the duplication you can use a Background to setup stuff that's common to all the scenarios in the file.

Cucumber step definition to ensure a list is created for me when I create a new account in a Rails 3 app

So I posted this to r/bdd and someone's comment gave me a eureka moment:

With Cucumber, I shouldn't be using steps that relate to such a granular level of my program. The current scenario is looking at the app through the eyes of a developer, when it should be looking at it through the eyes of a user.

Here's a re-write that uses a better viewpoint:

Scenario:
Given I am on the sign up page
When I create an account
Then I should be able to visit my list page

Cucumber should only be concerned with whether I can get there. It would be better at this point to drop down into something like RSpec to work out the details of how I get there (i.e. what the objects are doing rather than how they behave).

Cucumber - Javascript Invoke Login Step Definitions Before Other Step Definitions

Personally I don't think this is a good idea. To log someone in you have to specify 'who' the user is. Later when your application becomes more complex you might have interactions between different users. Hiding any of this from the scenario is not good.

What you can do is combine user specification and login in single steps e.g.

Given I am logged in as an admin
Given Fred is logged in as a sales executive

etc.

If you are clever about how you implement these steps you can keep things fairly dry by extracting helper methods from the step definitions and using global variables to store people e.g.

Given 'I am logged in as an admin' do
@i = create_user role: admin
login as: admin, user: @i

and reuse these methods in other login steps.

If you organise your features well, you can background alot of these calls e.g.

Feature: Basic admin ops
Background:
Given I am logged in as an admin

Scenario: I can foo
When I foo

Scenario: I can bar
When I bar

Some final thoughts ...

Each scenario is there to drive a particular piece of development. Compared to the work of doing the development writing "Given I am logged in" is trivial.

When something goes wrong knowing that you were supposed to be logged in is an essential piece of information.

How to link feature and step definition in cucumber

create a class YourClass and it would look something like the below and run it as JUnit test.

@RunWith(Cucumber.class)

@CucumberOptions( monochrome = true,
features = "src/dummy/pkg/features/",
format = { "pretty","html: cucumber-html-reports",
"json: cucumber-html-reports/cucumber.json" },
glue = "your_step_definition_location_package" )

public class YourClass {
//Run this from Maven or as JUnit
}


Related Topics



Leave a reply



Submit