On one of the lists I hang out at, Marton was wondering about how to start off a project that required authenticated users…
How would you decouple the sign-up feature from the login feature to keep the stories independent and testable from the UI only. The acceptance criteria should not fiddle with any implementation details such as concrete url-s or field types. I’d like to leave that entirely to the developers. Let’s say I have the following story coming to mind in a workshop:
As an Anonymous user I want to sign up to Example.com website to enjoy the benefits of a registered user.
Acceptance Criteria:
1. I navigate to the signup page
2. I enter my full name, desired username and my password
3. I have to verify my password to avoid any typos
4. I submit my information
And here comes the “tricky” bit:
5. I can log in with the credentials I provided.
Some folks suggested he start on real functionality first, others implied login was a lousy first story.
My take: It’s not a hard story to start at and have a meaningful test that can grow over time.
For example, to start, you can simply check that the response has “Login Succeeded” ( or “Login Failed” for testing that a bogus login attempt does indeed fail).
In Cucumber flavor:
Scenario: Registering as a new user
Given I am a new user
When I visit the site
Then I can register
Scenario: Logging in as a registered user
Given I am a registered user
Then I can login
And enjoy the beauty of the website
Or, even more simply:
Scenario: Successful Login
When I login as admin
Then I should be logged in
Scenario: Failed Login
When I login as asdf56ghasdkfh
Then I should be not logged in
And your steps would hide the logic for filling in the login form and checking for success:
Given /^I login as "([^"]*)"$/ do |login|
@login_name = login
visit login_path
fill_in "login", :with => login
fill_in "password", :with => "password"
click_button "login_button"
end
Then /^I should be logged in$/ do
response.should contain "Login Succeeded"
end
Then /^I should not be logged in$/ do
response.should contain "Login Failed. Please try again."
end
Your login details can change over time, adding the password confirmation box, handle validation errors, etc.
Your next step might be to show Admin-user-only functionality as I have here (snagged from a current app):
Feature: Quickly exercise the primary UIs just to make sure nothing blows up
Background: We need to pre-populate the database with the simulator results, and be logged in as admin
Given I login as "admin"
Scenario: Brief tour around the Admin UI
Then I should be able to click on "Dashboard" and see "Admin Management"
And I should be able to click on "Accounts" and see "Search"
And I should be able to click on "Sign out" and see "Login to Your Account"
And so it goes, step-by-step.
Hope that helps!
As an update… one of the list contributors went so far as to indicate “Login has Zero business value, always.” No wiggle room there!
well, okay, if you are parsing the act of logging in to achieve a status of an authenticated user to provide a means of secure access as separate from the need to have secure access, well, ok.
yes, i didn’t separate the two. The point was merely to show the OP how you could easily write his desired login and registration story, and it is not that hard.
As an aside, another project I did with two friends required a “marketing” site where you could sign up and see info about the core application. The project also required the site where registered users would do the real work of the application.
Since I knew login would be easy to add, I suggested to my one friend how to do it, and proceeded ahead with the other functionality. This was based on knowing full well that I would be able to feather in the user authentication and access rights into the core app once they were completed in the marketing app.
So, I am not hard over one way or the other on this issue, and in the past 12 months have done it both ways on different projects. Hence my surprise at folks’ having such stark “black and white” edicts banning ever starting at Login as a story.
Now, were I on a project where there was some very risky bit that, should we not solve that problem adequately, nothing else matters, guess where we start? Not login. 🙂
Geesh.
Oh, George posted a reply of sorts here.