Login testing ideas

Testing RSpec
1

I’ve been going through Pat’s example story and noticed that there was
no checking for a bad login. I assume this is because that would have
made the article bigger and more complicated than it needed to be.

So the question that comes of of this is:

How do folks normally handle the negative case? My plan was to just
use another scenario, but as a new person to BDD/TDD, etc, I didn’t
want to start teaching myself bad habits.

So my thought was to do something like:

Story “The saga of the login” do

Scenario “Good login” do
Given “a valid user/pass pair”, “gooduser”, “goodpass” do
#my needed code
end
Then “User should login ok” do
# more needed code
end
end
Scenario “Bad login” do
Given “a invalid user/pass pair”, “baduser”, “badpass” do
#my needed code
end
Then “User should get rejected” do
# more needed code
end
end
end

Another idea was to do this:
Story “The saga of the login” do

Scenario “Good login” do
Given “Logging in” do
#my needed code
end
When “with a valid user/pass pair”, “gooduser”, “goodpass” do
#my needed code
end
Then “User should login ok” do
# more needed code
end
When “with an invalid user/pass pair”, “baduser”, “badpass” do
#my needed code
end
Then “User should get rejected” do
# more needed code
end
end
end

This doesn’t even address the issue of a good user with a bad password,
but that seemed like overkill.

The second seemed more fluid for me.

Do people even bother with this level of granularity?

I’m probably over complicating the problem.

Thanks for any insight you can provide.

Mike B.

2

On 10/11/07, barsalou [email protected] wrote:

So my thought was to do something like:
end
Another idea was to do this:
# more needed code
This doesn’t even address the issue of a good user with a bad password,
Mike B.

I generally don’t even bother writing scenarios for bad logins.
Actually that’s not true…if I were to write an auth mechanism today,
I would write a login story, and that would involve good and bad
logins. But I’d only do it that one time.

In the rest of my stories I’d just write them assuming the login
worked. My controller specs all stub out authentication. I have a
“login_as mock_user” line which sets up a mock user and sticks it in
the session. Then I can stub out authorization methods as necessary.

describe VideosController, " requesting /videos/1 using GET" do
include UserSpecHelpers

before(:each) do
login_as mock_user
mock_user.stub!(:access_video?).and_return true
@mock_video = mock_model(Video)
Video.stub!(:find).and_return @mock_video
end

def do_get
get :show, :id => “1”
end

it “should find the video” do
Video.should_receive(:find).with(“1”).and_return @mock_video
do_get
end

it “should check to see if user is authorized” do
mock_user.should_receive(:access_video?).with(@mock_video).and_return
true
do_get
end

it “should render show.rhtml” do
do_get
response.should render_template(“show”)
end
end

describe VideosController, " requesting /videos/1 using GET, not logged
in" do
it “should redirect to the login page” do
get :show, :id => “1”
response.should redirect_to(login_url)
end
end

describe VideosController, " requesting /videos/1 using GET, not
authorized" do
include UserSpecHelpers

before(:each) do
login_as mock_user
mock_user.stub!(:access_video?).and_return false
@mock_video = mock_model(Video)
Video.stub!(:find).and_return @mock_video
end

it “should redirect to the login page” do
get :show, :id => “1”
response.should redirect_to(login_url)
end
end

Pat

3

def do_get
do_get
get :show, :id => “1”
@mock_video = mock_model(Video)

Pat

rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

Hi Pat and Mike,

I have login with role base authority and somehow didn’t want to make
new describe blocks for every role.
My current practice is using ‘with role’ like this:

describe PostsController, ‘/posts POST’ do
it ‘should redirect to login path’
it ‘with user should redirect to posts path’
it ‘with admin should redirect to admin favorite place etc’
end

I don’t like ‘when role is etc’ style at the end of spec because it
makes specs very blurry to overview. My project has still a few
behaviors still, perhaps later separation is a better way to go for
handle role stuff cleanly.

Priit