rspec users - Oct 2007 - Login testing ideas

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.



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On 10/11/07, barsalou <barjunk at attglobal.net>
wrote:
> 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.
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
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

> 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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> 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