Re: [rspec-users] Fwd: spec_server not working...

[Glenn Ford]

This is the same error that I get also.  I'd love to get this working,

Glenn

On Oct 31, 2008, at 5:04 PM, Nick Hoffman wrote:


On 2008-10-31, at 17:52, Matt Darby wrote:
Same thing unfortunately. It also happens when I add --drb to spec/ 
spec.opts and run autotest/autospec as well.


G'day Matt. This probably won't be of much help, but I've never been  
able to run my specs against spec_server. I always get this error:


/opt/local/lib/ruby/1.8/drb/drb.rb:852:in `initialize': getaddrinfo:  
nodename nor servname provided, or not known (SocketError)


Cheers,
Nick
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] ANN: RSpactor 0.9.10 (aka. beta)

[Glenn Ford]

Works for me!  However I have a feature request.  Currently I exclude  
certain files like so:

Autotest.add_hook :initialize do |at|
  %w{this_kind that_kind .git vendor .blah}.each {|exception|  
at.add_exception(exception)}

end

Will there be a way to do something like this with RSpactor?  I like  
having the ability to ignore certain files.  Some I skip because they  
don't work with my setup and to use RSpactor I have to comment out the  
whole file and remember not to accidentally commit it :)


Glenn

On Apr 29, 2008, at 3:17 AM, rubyphunk wrote:


If you have setup the binary as described in INSTALL.txt you can even
run rspactor from command line.
'cd' in your project directory and run 'rspactor'..

- andreas


On 29 Apr., 05:03, Zach Dennis [EMAIL PROTECTED] wrote:
Just put a directory path to a project in the text field, and click  
Run. It

will do the rest as far as I can tell,
Zach



On Mon, Apr 28, 2008 at 8:46 PM, Corey Haines  
[EMAIL PROTECTED] wrote:
Well, I got it running (seemingly), but I'm not 100% sure how to  
use it.

-Corey


On Mon, Apr 28, 2008 at 8:08 PM, Corey Haines  
[EMAIL PROTECTED]

wrote:



I'm using rspactor now over autotest. I'll give the beta a shot.
-Corey


On Mon, Apr 28, 2008 at 3:51 PM, rubyphunk  
[EMAIL PROTECTED]

wrote:



Hey all.


I've just release a first preview/beta of the upcoming  
RSpactor.app; a

spec runner for Mac OS X Leopard. This is just some kind of test
version and I'm looking for people who love to sit on the  
edge :) I

need some help to find bugs and polish the interface/interaction.



RSpactor is basically a tool like 'autotest' but runs on Cocoa and
focuses on RSpec. Instead of constantly polling your files it uses
FSEvents to listen to changes in your project directory. Growl  
support

is build in..



So if you are interested have a look at:


http://rubyphunk.com/2008/4/28/ann-rspactor-0-9-10-some-people-call-i 
...



thanks.
- Andreas
___
rspec-users mailing list
[EMAIL PROTECTED]
http://rubyforge.org/mailman/listinfo/rspec-users



--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines



--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines



___
rspec-users mailing list
[EMAIL PROTECTED]
http://rubyforge.org/mailman/listinfo/rspec-users


--
Zach Dennishttp://www.continuousthinking.com

___
rspec-users mailing list
[EMAIL PROTECTED]://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Multi-line steps

[Glenn Ford]

On Apr 9, 2008, at 5:04 PM, Pat Maddox wrote:

 On 4/9/08, Ashley Moran [EMAIL PROTECTED] wrote:

 On 9 Apr 2008, at 14:14, aslak hellesoy wrote:

 Just a style comment: I usually strive for a single When (in this  
 case
 Fred uploads the csv file).
 The other ones are Givens.

 Hmm, I've written a lot of Selenium stories lately, and they look  
 like
 this:

   Given ...

   When the user visits /my_page
   And clicks on Edit
   And types Cow in the favourite_animal text field
   And clicks the save button

   Then ...

 Is that bad?

 Not bad, but perhaps misleading. Given is used to express
 preconditions, wheras When is for an action. Her you are expressing
 preconditions, even if those preconditions are action-based instead of
 state-based (e.g. the known state of the work is that the user has
 performed these actions)

 Does that make any sense?

 Pat

This actually sounds more confusing to me when viewed in the context  
of my own stories, and it seems similar to what's going on here.  I  
write a lot about the user's interaction with the site and what should  
happen, so I have a lot of stories that look like:

Given database is in this state
When user does this stuff in browser
Then database should be in this new state

If the point of the Story is to see what happens when a user clicks  
buttons while the app is in a certain state, then moving those to a  
Given means you have no more actions left.  If all the action  
happened in the Given, then there won't be a When statement at all.

Glenn

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Multi-line steps

[Glenn Ford]

 This actually sounds more confusing to me when viewed in the context
 of my own stories, and it seems similar to what's going on here.  I
 write a lot about the user's interaction with the site and what  
 should
 happen, so I have a lot of stories that look like:

 Given database is in this state
 When user does this stuff in browser
 Then database should be in this new state


 This is a very technical way to express a scenario. It wouldn't make
 much sense to a typical domain expert (unless they know about
 databases).
 I generally try to write scenarios using the domain language,
 focussing on outcomes for users (not computers). Example:

 Given the customers joe, paul and lisa are registered users
 When a user signs up as lisa
 Then the user should be informed that the name is taken
 And the user lisa should not be able to log in

 Aslak

You're right, and I don't literally write them in this format.  But if  
you interpret the business logic that's in them into what they  
actually mean technically, it really just is the state of the database  
and I guess we can also add the session/cookies/flash.

Even in the example you just gave, you express in your Given that in  
the Users table of your db there are 3 entries.  For your When there  
is a user interacting with the web app.  Then shows that an error is  
in the response.

You could also check to ensure that the number of Users in the  
database did not change.  This, I know, is more of a technical way to  
look at it, but I've personally found use for this when realizing a  
tricky view was passing bad data to a controller and my Story caught  
it.  It was getting the right flash message in the end... but there  
were too many entities being created in the db.  I didn't catch this  
until the Story spec so I still think there's a use for this!

You could even break apart And the user... into:

  When a user tries to log in as lisa
  Then the user should be informed that no such customer exists

Because really the current statement includes multiple steps.  Going  
to the login page, filling out the data, submitting it, and then  
checking the response/redirect.  If there were an error in your Then  
the user $lisa should not be able to log in step, it would be  
untested and it's actually not quite trivial since it's not a single  
step.  That's probably more nit-picky since I'm sure the step would be  
used in many other places to give you added confidence, but since you  
mentioned When is for actions and your example And Then has an  
action, I still think it's interesting to look at :)

Glenn
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] how to mock/stub restful_authenticated and acl2-ized actions

[Glenn Ford]

While my approach might not be the best, since I don't  
stub :login_required, it still serves me well.  I would do something  
like this:

user = mock_model(User, :operator = true)
controller.stub!(:current_user).and_return(user)

login_required will find the 'current_user' and be happy.  I don't  
know if the :operator = true thing will cut it for your other check,  
but that should get you on the right track.

I hope that helps!
Glenn

On Apr 8, 2008, at 10:03 AM, Giuseppe Bertini wrote:

 Dear all,

 I am wondering how to properly mock/stub out the preliminary steps to
 actions protected by restful_authentication and acl_system2 (role- 
 based
 authorization to execute actions). Here's my setup:

 class User  ActiveRecord::Base
  has_and_belongs_to_many :roles
  has_many :tasks
  [snip]
 end

 class Task  ActiveRecord::Base
  belongs_to :user
 end

 I also have a Role class that habtm :users

 Now, for the controller that I need to spec:

 class TasksController  ApplicationController
  before_filter :login_required
  access_control :DEFAULT = 'operator'

  def index
@tasks = current_user.tasks
  end
 end

 Two interesting things happen here. First, access to the index  
 action is
 only granted after checking that the user is logged-in *and* that  
 she is
 an 'operator'. Second, the tasks method is called on current_user,  
 which
 is available to all controllers that include AuthenticatedSystem.

 I can easily write a few specs for this controller if I use a
 fixture_scenario and login_as (see below). On the other hand, I am
 trying to learn to abide to the hey, dont touch that! database  
 thing.
 As a novice, the task of setting up examples in which authentication 
 authorization are satisfied, and where current_user still responds
 properly appears daunting. But then again, I *am* a novice!

 Thank you all in advance,
 Giuseppe


 ###
 # my current specs
 ###
 include AuthenticatedTestHelper
 describe TasksController, with a logged-in user having 'operator'
 privileges do
  scenario :users_and_roles
  before(:each) do
login_as :giuseppe # based on the fixtures, giuseppe is now a
 logged-in operator
  end

  describe getting the index do

before(:each) do
  @tasks = mock_model(Task)
  Task.stub!(:find).and_return([EMAIL PROTECTED])
end

it should render index do
  get :index
  response.should render_template('index')
end

it should assign to the @tasks instance variable do
  get :index
  assigns[:tasks].should [EMAIL PROTECTED]
end
  end
 end
 -- 
 Posted via http://www.ruby-forum.com/.
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Need some help with a simple

[Glenn Ford]

I'm guessing the key is inside find_account_by_subdomain_or_url.  Do  
you have that defined somewhere?  It probably calls something like:

@account = Account.find_by_subdomain(blah) or Account.find_by_url(blah)

In which case that's probably what you need to stub.  Nothing is  
actually checking for the return value of the controller method or  
assigning it to @account.  In other words, you probably should do  
Account.stub! instead of controller.stub!  Check what's in that method  
and see if that gets you closer to the solution.

Good luck!
Glenn

On Apr 7, 2008, at 5:14 PM, chris anderson wrote:

 I can't figure out why this is failing.  It seems to have a hard time
 assigning the @account.  I have spent way too long trying to figure  
 this
 out.

 Thanks for any help.

 ---
 NoMethodError in 'StaffMembersController GET index should allow
 anonymous users'
 You have a nil object when you didn't expect it!
 The error occurred while evaluating nil.staff_members
 ---

 
 describe StaffMembersController do

  describe GET index do

before :each do
  @account = mock_model(Account, :staff_members =
 [mock_model(StaffMember)])
  controller.stub! 
 (:find_account_by_subdomain_or_url).and_return(@account)
end

# Authorization
it should allow anonymous users do
  get :index
  response.should render_template(:index)
end

  end
 end
 

 StaffMembersController
 
 class StaffMembersController  ApplicationController
  before_filter :find_account_by_subdomain_or_url

  def index
@staff_members = @account.staff_members
  end

 end
 +++
 -- 
 Posted via http://www.ruby-forum.com/.
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Stub an instance method for every new instance of a class

[Glenn Ford]

I think the general consensus is that if you need this feature, then  
you have ugly code that needs cleaning up :)  If you're in a situation  
like me, where you're too noob to figure out a better solution for  
some legacy code that you inherited, go to this url and find the  
instructions for installing Mocha:


http://wiki.rubyonrails.org/rails/pages/Testing+Plugins

With it you can do:
ModelName.any_instance.stubs(:the_method).returns(happy_times)

However, I strongly encourage you to stare at your current code for a  
while and try to find a cleaner MVC-supportive solution.  The general  
rule of thumb is that if it's difficult to write a spec for, then your  
code is ugly :)  Hopefully in this case you can take this as an  
opportunity to improve your code.  If not, Mocha works fairly well!


Glenn

On Apr 1, 2008, at 3:50 AM, Ashley Moran wrote:


On 01/04/2008, Jed Hurt [EMAIL PROTECTED] wrote:
Is there an easy way to stub an instance method for every new  
instance of a given class? I suppose I could just redefine the  
method, but I'm wondering if the RSpec mocking framework has this  
built in.


Hi Jed

I hate it when other people ask this, but I can't help :)  How come  
you need to do this?  I've always wondered what the use case for  
this mocking strategy is


Ashley
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Confusing error with GivenStory

[Glenn Ford]

Hey all!  I'm loving Stories so far, but I ran across a difficult  
error today that I felt should have resulted in a PENDING message.   
Here's what I got:


/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/scenario_runner.rb:11:in  
`run': You have a nil object when you didn't expect it! (NoMethodError)
The error occurred while evaluating nil.story	from /Users/Malohkan/ 
Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/rails/ 
story_adapter.rb:69:in `perform'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/world.rb:52:in  
`run_given_scenario_with_suspended_listeners'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/world.rb:101:in  
`GivenScenario'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
115:in `send'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
115:in `to_proc'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
95:in `instance_eval'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
95:in `to_proc'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
95:in `each'

 ... 6 levels...
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_runner.rb: 
39:in `each'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner/story_runner.rb: 
39:in `run_stories'
	from /Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/ 
spec/rails/../../../../rspec/lib/spec/story/runner.rb:44:in  
`register_exit_hook'


The only thing I could deduce was that it had something to do with  
GivenScenario.  The problem was that I had misspelled the name of the  
Scenario I was trying to run with GivenScenario.  However if you  
misspell a Step, you get it marked as PENDING and the ones below it as  
FAILED.


Once I realize this my first thought was, Great!  A chance to write  
my own patch!  Unfortunately I think my rails-fu is still too weak.   
I hacked around with it for a while but couldn't duplicate the  
behavior like I was hoping.  So the best I can do for now is to try to  
point those who can in the right direction.


I think that the exception should be caught on line 52 of world.rb.   
The one with scenario.perform(world, name) on it.  Below in the  
following method I see where step.perform(world, *args) gets called  
and is wrapped with begin/rescue.


If catching the exception isn't the right way to go, then check line  
66 of story_adapter.rb which has  
StoryRunner.scenario_from_current_story.  This call does a .find()  
and returns nil.  That's the first place it's made known that this  
Scenario doesn't exist.


I hope this helps!

Glenn___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Confusing error with GivenStory

[Glenn Ford]

I sent a reply just a couple minutes later... to myself only :P  Sorry  
about that.  Here what was I sent:


Here's a lighthouse ticket:
http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/354-confusing-error-with-givenscenario

By the way I just realized I typo'd GivenStory in the subject which  
should have been GivenScenario.  I guess I'm full of typos today!


Glenn

On Mar 31, 2008, at 11:34 AM, David Chelimsky wrote:

On Mon, Mar 31, 2008 at 11:16 AM, Glenn Ford [EMAIL PROTECTED]  
wrote:
Hey all!  I'm loving Stories so far, but I ran across a difficult  
error
today that I felt should have resulted in a PENDING message.   
Here's what

I got:


/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/scenario_runner.rb: 
11:in
`run': You have a nil object when you didn't expect it!  
(NoMethodError)

The error occurred while evaluating nil.story from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/story_adapter.rb:69:in

`perform'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/world.rb:52:in

`run_given_scenario_with_suspended_listeners'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/world.rb:101:in

`GivenScenario'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
115:in

`send'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb: 
115:in

`to_proc'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb:95:in

`instance_eval'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb:95:in

`to_proc'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_mediator.rb:95:in

`each'
... 6 levels...
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_runner.rb:39:in

`each'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner/story_runner.rb:39:in

`run_stories'
from
/Users/Malohkan/Sites/blog/vendor/plugins/rspec_on_rails/lib/spec/ 
rails/../../../../rspec/lib/spec/story/runner.rb:44:in

`register_exit_hook'

The only thing I could deduce was that it had something to do with
GivenScenario.  The problem was that I had misspelled the name of the
Scenario I was trying to run with GivenScenario.  However if you  
misspell a

Step, you get it marked as PENDING and the ones below it as FAILED.

Once I realize this my first thought was, Great!  A chance to  
write my own
patch!  Unfortunately I think my rails-fu is still too weak.  I  
hacked
around with it for a while but couldn't duplicate the behavior like  
I was
hoping.  So the best I can do for now is to try to point those who  
can in

the right direction.

I think that the exception should be caught on line 52 of  
world.rb.  The
one with scenario.perform(world, name) on it.  Below in the  
following
method I see where step.perform(world, *args) gets called and is  
wrapped

with begin/rescue.

If catching the exception isn't the right way to go, then check  
line 66 of
story_adapter.rb which has  
StoryRunner.scenario_from_current_story.
This call does a .find() and returns nil.  That's the first place  
it's made

known that this Scenario doesn't exist.

I hope this helps!


Please post this to http://rspec.lighthouseapp.com.

Thanks,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Trouble with my first Story

[Glenn Ford]

Hi all!  I've been through the RSpec Stories PeepCode and some various  
other readings online, and now I'm trying to build a dummy application  
of the traditional style: log in, make posts, add comments.

So I've run the scaffold for posts/comments and the script for  
RestfulAuthentication so I have the users and SessionController and  
all that set up in this project.  Now I've written this story:

http://pastie.caboo.se/pastes/171140

In it I'm trying to do a post to /session/create in order to log  
in.  I figure I want to be able to call this from an Story so that I  
can reuse it for different scenarios when I want to test things  
requiring login.

What am I doing wrong here?

Thanks!
Glenn
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Trouble with my first Story

[Glenn Ford]

On Mar 26, 2008, at 6:28 PM, Chuck Remes wrote:


 On Mar 26, 2008, at 4:02 PM, Glenn Ford wrote:
 Hi all!  I've been through the RSpec Stories PeepCode and some  
 various
 other readings online, and now I'm trying to build a dummy  
 application
 of the traditional style: log in, make posts, add comments.

 So I've run the scaffold for posts/comments and the script for
 RestfulAuthentication so I have the users and SessionController and
 all that set up in this project.  Now I've written this story:

 http://pastie.caboo.se/pastes/171140

 In it I'm trying to do a post to /session/create in order to log
 in.  I figure I want to be able to call this from an Story so that I
 can reuse it for different scenarios when I want to test things
 requiring login.

 What am I doing wrong here?

 Glenn,

 please include a pastie that shows the error you are getting or the
 behavior that isn't working.

 cr

Oh sorry about that... it was there before I promise :)

FAILURES:
 1) User Stuff (Create a new user) FAILED
 Spec::Expectations::ExpectationNotMetError: expected redirect? to  
return true, got false
 stories/user_story.rb:34:in `I should be logged in'
stories/user_story.rb:31
stories/user_story.rb:3

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Trouble with my first Story

[Glenn Ford]

It actually should do a redirect, but checking for response.should  
be_success also fails.  The request isn't actually being made.  I just  
can't figure out why.

Glenn

On Mar 26, 2008, at 8:19 PM, Matt Berther wrote:

 Hi Glen,

 I do not mean to insult you, but is /session/create actually doing a
 redirect? A similar rspec test works for me.

 --
 Matt Berther
 http://www.mattberther.com




 On Mar 26, 2008, at 5:51 PM, Glenn Ford wrote:

 On Mar 26, 2008, at 6:28 PM, Chuck Remes wrote:


 On Mar 26, 2008, at 4:02 PM, Glenn Ford wrote:
 Hi all!  I've been through the RSpec Stories PeepCode and some
 various
 other readings online, and now I'm trying to build a dummy
 application
 of the traditional style: log in, make posts, add comments.

 So I've run the scaffold for posts/comments and the script for
 RestfulAuthentication so I have the users and SessionController and
 all that set up in this project.  Now I've written this story:

 http://pastie.caboo.se/pastes/171140

 In it I'm trying to do a post to /session/create in order to log
 in.  I figure I want to be able to call this from an Story so  
 that I
 can reuse it for different scenarios when I want to test things
 requiring login.

 What am I doing wrong here?

 Glenn,

 please include a pastie that shows the error you are getting or the
 behavior that isn't working.

 cr

 Oh sorry about that... it was there before I promise :)

 FAILURES:
1) User Stuff (Create a new user) FAILED
Spec::Expectations::ExpectationNotMetError: expected redirect? to
 return true, got false
stories/user_story.rb:34:in `I should be logged in'
 stories/user_story.rb:31
 stories/user_story.rb:3

 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Trouble with my first Story

[Glenn Ford]

That was it, thank you!  Must have been a long day, I can't believe I  
didn't spot that :)

On Mar 26, 2008, at 10:15 PM, David Chelimsky wrote:

 On Wed, Mar 26, 2008 at 5:02 PM, Glenn Ford [EMAIL PROTECTED] wrote:
 Hi all!  I've been through the RSpec Stories PeepCode and some  
 various
 other readings online, and now I'm trying to build a dummy  
 application
 of the traditional style: log in, make posts, add comments.

 So I've run the scaffold for posts/comments and the script for
 RestfulAuthentication so I have the users and SessionController and
 all that set up in this project.  Now I've written this story:

 http://pastie.caboo.se/pastes/171140

 Shouldn't that be a post to /sessons/?


 In it I'm trying to do a post to /session/create in order to log
 in.  I figure I want to be able to call this from an Story so that I
 can reuse it for different scenarios when I want to test things
 requiring login.

 What am I doing wrong here?

 Thanks!
 Glenn
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Why not MockEverthing or why use fixtures for all tests?

[Glenn Ford]

 to any domain level objects (models and
 non-models alike). You can't do this approach with state-based testing
 only. There is a lot of value that can be gained by developing
 software this way.

 In short: Interaction-based testing allows you to ensure that an
 object is doing what you expect, without the underlying implementation
 having to exist yet at all or in full. It is great for application
 layer objects which typically only coordinate domain layer objects
 where the correct interaction is what is important. It also helps you
 develop interfaces, and it can scream loudly when you have an object
 doing way too much.

 * Blaming brittleness of tests upon interaction-based testing is a
 red herring. Both interaction-based tests and state-based tests become
 brittle if they make assertions upon implementation details and overly
 constrain the interfaces between modules. - Nat Pryce

 * http://nat.truemesh.com/archives/000342.html - a wonderful read on
 interaction-based vs state-based testing

 --  
 Zach Dennis
 http://www.continuousthinking.com
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users


A lot of what you say makes me wish I was more experienced in this  
department :)  I am very new to this!  A part of me wishes I had the  
knowledge to write in the order of story - view spec - controller  
spec - model spec.  However most of the time (I emphasize MOST) I  
don't have the foresight to do that.  The problem I'm trying to solve  
is almost always too complicated for me to know right away where to  
really start (my latest client has some crazy ideas).  Maybe the  
problem is that I make things too complicated for myself :)  However I  
have been a developer (just not using RSpec) for a very long time so I  
know fairly well how to recognize when things need to be complicated  
and when they don't.  This means .should_receive is often out of the  
question because I have no idea what the model should receive!

My primary concern when writing my specs that are to cover complicated  
features is that I do NOT want false confidence.  If I write a spec,  
and it passes, I want that to mean it works in my app.  When the spec  
goes green, my next step is to go hit Refresh in my browser.  If it  
doesn't work in my browser, then in my opinion, my spec is crap.  It's  
telling me things work when they don't.

I hear the concern being voiced that if you break one thing and 15  
specs pass then you're not mocking enough.  Well since this is BDD,  
after all, then we should be working closely to the current spec we're  
trying to make pass.  I change code, and 15 specs break, well I have a  
good idea of what code got broken because it's the top-most file in my  
editor!  I hit save, Autotest screamed at me, I'm going to go hit undo  
now.

Sometimes I make noob decisions and give model A a certain  
responsibility when it should have been done by model B.  I get it to  
work in the short term, my spec's pass, but later I need to add  
another feature and realize that old responsibility needs to be moved  
from A to B.  Now I have a red spec and X green specs.  I move that  
responsibility, X specs are green, with still the same 1 red spec.  I  
implement the new feature, X+1 green specs.  I refresh in my browser,  
sure enough, it all works.  I didn't have to go change all of my stubs  
and should_recieve's everywhere that just got moved.  There's no need  
to, because my specs cover the true business logic behavior, and not  
the model-specific behavior.

While I do certainly believe the ability to spread everything out well  
enough so that 1 error = 1 broken spec comes from great wisdom and  
experience, I certainly don't have it, and I don't want to encourage  
others like me to try to strive for that because I don't know how to  
teach them from my own example.  What I do know, is that I use a lot  
of real models, and I don't spend any time fixing specs that are  
broken by working code.  I did that on my last project and it, in my  
opinion, wasn't worth it.  I'd change a variable assignment with  
a .save to a .update_attribute and then I had a broken spec.

My fear is that I'll write green specs, pat myself on the back, and  
then my company loses money because the site has bugs that my specs  
show green for because I don't have enough integration tests or  
whatever.  But I don't want to have to double my tests for the same  
amount of coverage.  I should have 1 spec for 1 feature and when that  
feature is working, that spec is green, plain and simple.  I admit I  
may be ignorant to a lot of the power behind RSpec, but I like this  
level of simplicity and straightforwardness.

Glenn Ford
http://www.glennfu.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Why not MockEverthing or why use fixtures for all tests?

[Glenn Ford]

On Mar 19, 2008, at 1:03 PM, David Chelimsky wrote:

 On Wed, Mar 19, 2008 at 10:42 AM, Glenn Ford [EMAIL PROTECTED]  
 wrote:
 [Big Snip]



 There are a few bad assumptions in your colleague's response, so to
 set the record straight:

 * test coverage and tests which use the interaction-based test
 approach are not mutually exclusive
 * you can have crappy tests which take the state-based approach and
 crappy tests which use a interaction-based approach
 * interaction-based testing is not merely limited to contrived
 examples on people's blogs, it is a real practice which adds value  
 on
 lots of real-world projects
 * using factories to generate required objects in tests has several
 pros over the use of fixtures, and very very very few cons

 State-based testing and interaction-based testing both have their
 place. There are number of reasons why they are both useful, but I'm
 going to pick two: object decomposition (and coordinators) and
 integration testing. Others have mentioned the value of writing  
 tests
 with the interface you want so I'm going to leave that out.

 As an application grows in features and complexity (business logic  
 of
 course) good developers will decompose the problem into a number of
 simple objects. Some of these objects are responsible for doing the
 work and others are responsible for coordinating other objects to do
 the work. Objects which are responsible for coordinating are great
 candidates for using interaction-based testing, because you are
 concerned in the interaction, not the state.

 If you don't have integration tests then using an interaction-based
 testing approach is not worth it because you need something that is
 going to test the real objects working with real objects. In Rails  
 you
 can write integration tests as Rail's
 ActionController::IntegrationTests, Rail's functional tests, RSpec
 stories, or RSpec controller tests w/view isolation turned off.

 IMO, one false benefit of only using a state-based approach when
 writing a full-fledged application is that every object is  
 essentially
 an integration test at some level. You are always testing everything
 with everything that it touches. This can lead to having one failure
 in one model make several other model tests fail, and it can make
 several controller tests failing (as well as any other object which
 touches the model that is failing). I see this has a big negative
 because it makes it more difficult to pinpoint the issue. People  
 will
 end up tracking it down, but it can be time consuming and  
 frustrating.

 Now on the flip side people will complain that they renamed a model
 method and re-ran all of their tests and everything passed, but when
 running the application a bug exists. Doh, we forgot to update the
 controller that relied on calling that model method. It is normal to
 say/think, well that should have failed because the method doesn't
 exist on the model. (It sounds like David Chelimsky may have
 something in trunk to help with this.) The main problem here  
 though is
 that an integration test didn't fail exposing that you weren't done
 with your change.

 Thinking back to coordinating objects, my controllers don't contain
 business logic in them because they are application layer classes,
 they aren't apart of the domain of my software. They are only used  
 by
 the application to allow the software to fulfill the requirements of
 my customer. Controllers are coordinators, not DOERS. They ask other
 objects to fulfill a business requirement for them like moving  
 stocks
 from one portfolio to the another. So I used interaction-based  
 testing
 here to ensure that my controller is finding a stock, finding a
 portfolio and asking a portfolio manager to move the stock to the
 designed portfolio. I don't need to have those things written or  
 even
 fully implemented to ensure my controller works as I expect. I  
 should
 be able to see that my controller does what it should be doing, even
 if the pieces it will use to do the work in the application aren't
 finished. Now if those aren't implemented I should have an  
 integration
 test which fails showing me that the feature for moving stocks from
 one portfolio to another is not completed, but that isn't what I'm
 testing in my controller.

 Also after my controller works as expected I can go make sure the
 PortfolioManager works as expected, and then I can go down and make
 sure the Stock model does what I expect. When these objects are
 working correctly individual I run my integration tests to ensure  
 they
 work well together.

 Another drawback of only using state-based testing is that you  
 always
 have to develop bottom up. You have to start with the low level
 components and work your way out. I used to write code this way. I
 think I have progressed beyond that, and now I write things in a
 Acceptance Test Driven Development style. I start by writing an
 integration test from the user's perspective proving

Re: [rspec-users] bad specs better than none?

[Glenn Ford]

I have a similar perspective from my own personal experience.  I am  
still quite the novice, but I'm as much of a novice in RSpec as I am  
in Ruby / RoR.  Honestly, a lot of my specs in new sections end up  
having great coverage, but are full of real models and few of the  
purist BDD practices.  Before I started with BDD I did a lot of  
reading so I feel that I have a good understanding of the goal, and I  
do have some specs with little database access and great  
implementation of the MVC goodness that RoR supports, but I simply  
can't always keep this up even when I want to.

A lot of times if I'm writing some code for a challenging piece, it's  
challenging to me because I don't already know how to do it.  I can  
write the basic here's the setup, result.should eql(this_thing) but  
I can't write any mocks/stubs/should_receives in the middle because at  
every step, I just honestly have no idea how it should work!!  So I  
throw in real models and try to make it as real as possible, rather  
than as pure as possible.  It's not until after I get things working  
that I even know what the solution should remotely look like.  This is  
due to my inexperience that I have to hack around a lot before I  
figure out how to make things work.  Unfortunately, I know this means  
I write code that is more complicated than it should be, but if I  
can't figure out a better way, I have to write something that still  
works!

So while I have a lot of the knowledge behind the theory of good BDD  
practice, I can't always implement it even when I want to.  My Ruby /  
RoR inexperience is what holds me back the most in that department.   
It's just something I have to cultivate really.  Until then I'm happy  
with my green specs with excellent coverage that slam the database  
like crazy and take a long time and have few mocks/stubs/ 
should_receives.

Glenn

On Feb 27, 2008, at 10:45 PM, Kero wrote:

 I also had to go into specs on a project I'm not working on, and  
 found
 an unholy hive of database-accessing specs. It's disheartening.
 Basically, it's cargo cult development practices - using the best
 practice without actually understanding it.

 This is a really tough problem. The whole motivation for BDD was
 people don't get TDD, so let's come up with some new ways to frame  
 it
 so people get it. Now people don't get the new frame. In that  
 respect
 we've made things twice as bad.

 What did you expect? Honestly?
 You need to show people the Right way, otherwise they're unlikely to  
 figure
 it out by themselves. But as the fortune cookies go:
 To make the right decision, one needs experience.
  To gain experience, one needs to make the wrong decision.

 It is easier for me to explain this from the point of view of aikido:
 I've been shown the right moves thousands of times. I can not even see
 what sensei does, let alone reproduce it. I can not perceive the  
 balance,
 the timing, the acceptance of an attacker and the reflection of his/ 
 her
 energy to -ultimately- unbalance. How could I learn by trying even  
 tens
 or hundreds of thousands of time?
 After seven years, I'm still a puny beginner. And I need other people
 to show me my mistakes. Again, again and again.

 To the original poster: yes, teach BDD.
 Make sure they accept you as a teacher,
 then teach, small steps at a time, by showing what is wrong.
 when they figure out a solution by themselves, encourage them, accept
 that solution (use it yourself). When they don't figure it out by
 themselves (likely enough), show how you would do it.
 And be prepared to repeat yourself.

 HtH,
 Kero.
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Cookie Session Store Not Working in Safari

[Glenn Ford]

Here's the steps I followed:

Generated the test code
rails test
mate test
cd test
script/generate scaffold thing
rake db:create
script/server


Modified things_controller.rb index and new:
def index
end
def new
session[:user] = 5
redirect_to(things_path)
end

Set index.html.erb to:
Hello! %= session[:user] %
%= link_to 'New thing', new_thing_path %

---

Now when I go to the page in FireFox, I see Hello on the screen.   
Clicking the link gives me Hello 5 on my screen.  This is expected.


However, when I go to Safari, I only ever see Hello and never Hello  
5.  I have, in the Safari preferences, accept cookies set to Accept  
All.  I've checked everything I can think of to make sure nothing is  
blocking it.


I've inspected the session and the only thing I can find is that the  
Session ID for the Safari requests is a new 32 character string for  
every request, and for FireFox requests it's the same 128 character  
string for every request.


I'm using Ruby on Rails 2.0.2.  I hope I'm not forgetting some other  
useful piece of info.


How do I get this to work for me in Safari?

Thanks,
Glenn___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Cookie Session Store Not Working in Safari

[Glenn Ford]

Whoops, you're very right, this isn't the RoR list!  Oh well it's the  
only one I ever use.  My bad!  Let's look at it this way... my spec's  
are failing because I can't use session!  What do I do? :)

On Jan 2, 2008, at 11:36 PM, Giles Bowkett wrote:

 Sorry, I'm new here, but isn't this totally irrelevant to RSpec in  
 every way?

 On 1/2/08, Glenn Ford [EMAIL PROTECTED] wrote:

 Here's the steps I followed:

 Generated the test code
 rails test
 mate test
 cd test
 script/generate scaffold thing
 rake db:create
 script/server


 Modified things_controller.rb index and new:
 def index
 end
 def new
 session[:user] = 5
 redirect_to(things_path)
 end

 Set index.html.erb to:
 Hello! %= session[:user] %
 %= link_to 'New thing', new_thing_path %

 ---

 Now when I go to the page in FireFox, I see Hello on the screen.   
 Clicking
 the link gives me Hello 5 on my screen.  This is expected.

 However, when I go to Safari, I only ever see Hello and never  
 Hello 5.
 I have, in the Safari preferences, accept cookies set to Accept  
 All.  I've
 checked everything I can think of to make sure nothing is blocking  
 it.

 I've inspected the session and the only thing I can find is that  
 the Session
 ID for the Safari requests is a new 32 character string for every  
 request,
 and for FireFox requests it's the same 128 character string for every
 request.

 I'm using Ruby on Rails 2.0.2.  I hope I'm not forgetting some  
 other useful
 piece of info.

 How do I get this to work for me in Safari?

 Thanks,
 Glenn
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users



 -- 
 Giles Bowkett

 Podcast: http://hollywoodgrit.blogspot.com
 Blog: http://gilesbowkett.blogspot.com
 Portfolio: http://www.gilesgoatboy.org
 Tumblelog: http://giles.tumblr.com
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] helper methods starting with should

[Glenn Ford]

-1
I, as a new rspec user, did not find the switch between test_ and it  
blah do to be even a small challenge compared to other things I had  
to convert and learn.  I only feel like it would be one more thing to  
keep up with that would cause problems.  I can certainly see someone  
writing a helper method with should_ and saying what the heck is  
going on because they didn't fully read all the documentation.  It  
was plenty easy in my conversion to say oh ok, find and replace test_  
and put it should in place of that.  I would have certainly been  
frustrated to find a hidden feature causing problems that I didn't  
understand.

Keeping in mind my original n00b perspective, I feel like if in my  
first impression I had the option of turning on a baby-step feature  
that I might have either, A - not known about it because I didn't see  
it in my first tutorial, or, B - skipped it feeling that I could  
handle making that transition into the accepted way.

I can see how some people might find use for it, but I believe overall  
the complexity would cause more confusion than it would prevent.

There's my 2 cents.

Glenn

On Nov 18, 2007, at 1:52 PM, Shane Mingins wrote:


 On 19/11/2007, at 5:05 AM, Nathan Sutton wrote:

 0

 Keep it, but make it a configuration option with default-off.

 Nathan Sutton
 [EMAIL PROTECTED]
 rspec edge revision 2894
 rspec_on_rails edge revision 2894
 rails edge revision 8146



 I agree.  +1 configuration with default being current behaviour.

 Cheers
 Shane

 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Trouble using should_receive

[Glenn Ford]

I have this code trying to ensure my reset method works.  I want to  
make sure all the participants have their destroy method called.


# in my spec for Room
r = Room.new(:name = 'bob')
r.save

p = Participant.new(:login = 'a', :password =  
'b', :password_confirmation = 'b')

p.room = r
p.save!
p.should_receive(:destroy)

r.reset

#in room.rb
  def reset
participants.each { |p| p.destroy }
save!
  end

Unfortunately it fails.  I print out p in both locations and while  
they have all the same data, they have different memory addresses.  I  
don't know if this is the explanation for the issue but it's all I can  
find so far.


How do I fix this?  Thanks!

Glenn___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Trouble using should_receive

[Glenn Ford]

On Nov 15, 2007, at 2:03 PM, Pat Maddox wrote:

 On Nov 15, 2007 10:50 AM, Glenn Ford [EMAIL PROTECTED] wrote:

 I have this code trying to ensure my reset method works. I want to  
 make sure
 all the participants have their destroy method called.

 # in my spec for Room r = Room.new(:name = 'bob') r.save p =
 Participant.new(:login = 'a', :password =  
 'b', :password_confirmation =
 'b') p.room = r p.save! p.should_receive(:destroy) r.reset #in  
 room.rb def
 reset participants.each { |p| p.destroy } save! end

 Unfortunately it fails. I print out p in both locations and while  
 they
 have all the same data, they have different memory addresses. I  
 don't know
 if this is the explanation for the issue but it's all I can find so  
 far.

 How do I fix this? Thanks!

 Glenn
 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users


 Hey Glenn,

 The problem, as you mentioned, is that the objects loaded by
 #participants don't include the object you created.  Rails does a
 SELECT * FROM participates WHERE room_id=? and instantiates new
 objects.

 The first option is to use participants# instead of setting the
 room.  So instead of
 p.room = r

 you would have
 r.partipants  p

 And then it ought to work.

 Alternatively, since you're actually hitting the database, you can  
 just do

 lambda { r.reset }.should change(Participant, :count).by(-1)

 And as a side note, AR gives you #destroy_all, so instead of iterating
 through the participants you can just do
 participants.destroy_all

 hth

 Pat

r.participants  p didn't do it, but the should change did and I  
like that solution best.  Court3nay also suggested r.stub! 
(:participants).and_return([p]) which works also.

Thanks for your help, and thanks for the extra destroy_all trick too!

Glenn


 ___
 rspec-users mailing list
 rspec-users@rubyforge.org
 http://rubyforge.org/mailman/listinfo/rspec-users

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Interdependency between RSpec files

[Glenn Ford]

I run my suite of tests, one test fails.
I run that one test file, no tests fail.

Something is carrying over between files and I can't figure out what.   
I tracked down the problem to the very line it's occurring on, with  
printouts before and after every call to make sure I know exactly what  
is being reached.

In this spec I have 0 fixtures/mocks/stubs.  The objects in this file  
do not live anywhere outside of the file.  This is a model spec and  
I'm using all real objects to test it.  In the before block I set up  
some models, and in my spec itself I, in each test, make a couple  
changes then call a model's save method.  That model has an  
after_create method which calls a method in a child model that it  
has.  It is THIS method which is not being called.  I have printouts  
before and after everything, like I said, and the lines before and  
after the method call work, which leads me to believe that method IS  
getting called.  However I have a puts 'foo' at the top of that  
method and it doesn't get printed.

The object is not nil, and it has even been successfully saved  
previously in the code, and all of its necessary attributes have been  
set.  Why on earth is it not getting called?  Keep in mind, it DOES  
get called if I run spec on that specific file.  If I run it among  
my other spec files (I've got lots) it DOES NOT get called.

I need some ideas on how to chase this one down?  I stuck printouts  
everywhere to track the issue down as narrowly as I have but I'm down  
to a single line and it's doing something I didn't even know was  
physically possible in this language.  It seems I must be overlooking  
something but I just can't seem to see outside of the box on this  
issue.  Any ideas would be great, thanks!

Glenn
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Plain Text Story example

[Glenn Ford]

That was exactly what I needed, thanks a lot!

Glenn

On Nov 9, 2007, at 10:59 AM, Dan North wrote:


Hi Glenn.

On Nov 8, 2007 4:01 PM, Glenn Ford [EMAIL PROTECTED] wrote:
It seems that what I'm coming to understand of the direction of this
story concept is that there is a lot of emphasis being put on ensuring
we keep things at the business level.  I can appreciate the elegance
of it certainly, but when I think of what I would really want to gain
from this story-based testing process, I feel like it cuts out room
for some really cool ideas.  Maybe you can help me see where they
would fit.

I have in mind a scenario where a customer says I tried to log in and
it blew up!  I take what they say with a business perspective and
check my story and say hey I've got a login story and it works but
that doesn't leave room for the fact that, slighty away from the norm
of the usual login procedure, this particular user clicked another
link in the middle of the process that changed some background
variable, breaking the process at the final login step.  I would then
want to write a story similar to the usual login, but with the ACTUAL
details of what the customer did to ensure I could duplicate, fix, and
then never have this problem creep up again.

I completely agree.

 My story, in order to be
of use to me, would HAVE to have steps like click this button
because, quite frankly, as a developer I find that's the sort of thing
that can break my code and so I would want a story to account for it.

Yes, exactly. In this example, the UI domain is the most useful  
domain to express the (bogus) behaviour, so it's the right thing to  
do. The scenario might be something like:


Scenario: press the Explode button whilst filling in form

Given I navigate to the Submit order page   [I'm loving these infix  
parameters!]

And I set first name to Dan and second name to North
When I click the Explode button
Then nothing should happen
And the current page title should be Submit order

Now, the whole of this scenario is in UI domain terms. It doesn't  
matter what business function I'm trying to achieve here - the  
description is about some bogus behaviour in my implementation (the  
Explode button should be disabled whilst I'm capturing data)


So it's fine to express scenarios in either business domain terms to  
describe actual business flow, or UI terms to describe the user's  
interactions with the application. The confusion starts when you mix  
the two domains in the same story or at least in the same scenario.



A user following my intended user-flow, then deviating in a way I
didn't predict.  From the business end, they still followed the login
process, they just had one little different quirk along the way.

Yes, and it's that quirk in this particular UI that you want to  
capture with this scenario.


Is there a way to get this kind of thing but still keep to the ideal
business perspective?

You're trying to do a different thing here. The audience is  
different (probably a tester or UI designer rather than a business  
stakeholder) and they'll be using a different vocabulary.


Would I just simply word it in a way that the
simple little thing they did had a business description?  Or is that
an indication that I have stupid things on my page that shouldn't even
be an option?  Or is there a happy medium here as well between
business and ui perspectives of stories?

See above - as long as you keep the distinction between domains when  
you are describing a scenario, you'll probably be ok.


Glenn

Cheers,
Dan



On Nov 8, 2007, at 6:58 AM, David Chelimsky wrote:

 On Nov 8, 2007 12:17 AM, Ben Mabey [EMAIL PROTECTED] wrote:
 David Chelimsky wrote:

 snip

 ... the philosohy that Dan is
 espousing: expressing stories in the business domain rather than  
the

 UI domain (btw Dan, that was brilliantly put).
 What exactly do you and Dan mean when you say that the stories
 should be
 expressed in the business domain rather than the UI domain?   
(BTW, is

 there a link to a Dan North post abou that?)

 Sorry - there are two different threads going on about this topic
 right now - the other one is on the rspec-devel list and that was
 where Dan posted that statement:

 http://rubyforge.org/pipermail/rspec-devel/2007-November/004259.html

 Keep in mind that User Stories are oft described as a token for a
 conversation, and that even with acceptance criteria spelled out,
 whether the button says Create New Account or Enter is rarely of
 sufficient business value to express that in a story. That's the  
sort
 of detail that comes out when you say to your customer the entry  
form
 is done, why don't you come by so I can show it to you, as  
opposed to

 in the iteration planning meeting.

 In the end it really does boil down to what the customer feels is
 necessary in order to accept the software. If the customer really  
DOES
 care about what the button says, he or she may want that expressed  
in
 a story. But even

Re: [rspec-users] Plain Text Story example

[Glenn Ford]

It seems that what I'm coming to understand of the direction of this  
story concept is that there is a lot of emphasis being put on ensuring  
we keep things at the business level.  I can appreciate the elegance  
of it certainly, but when I think of what I would really want to gain  
from this story-based testing process, I feel like it cuts out room  
for some really cool ideas.  Maybe you can help me see where they  
would fit.

I have in mind a scenario where a customer says I tried to log in and  
it blew up!  I take what they say with a business perspective and  
check my story and say hey I've got a login story and it works but  
that doesn't leave room for the fact that, slighty away from the norm  
of the usual login procedure, this particular user clicked another  
link in the middle of the process that changed some background  
variable, breaking the process at the final login step.  I would then  
want to write a story similar to the usual login, but with the ACTUAL  
details of what the customer did to ensure I could duplicate, fix, and  
then never have this problem creep up again.  My story, in order to be  
of use to me, would HAVE to have steps like click this button  
because, quite frankly, as a developer I find that's the sort of thing  
that can break my code and so I would want a story to account for it.   
A user following my intended user-flow, then deviating in a way I  
didn't predict.  From the business end, they still followed the login  
process, they just had one little different quirk along the way.

Is there a way to get this kind of thing but still keep to the ideal  
business perspective?  Would I just simply word it in a way that the  
simple little thing they did had a business description?  Or is that  
an indication that I have stupid things on my page that shouldn't even  
be an option?  Or is there a happy medium here as well between  
business and ui perspectives of stories?

Glenn

On Nov 8, 2007, at 6:58 AM, David Chelimsky wrote:

 On Nov 8, 2007 12:17 AM, Ben Mabey [EMAIL PROTECTED] wrote:
 David Chelimsky wrote:

 snip

 ... the philosohy that Dan is
 espousing: expressing stories in the business domain rather than the
 UI domain (btw Dan, that was brilliantly put).
 What exactly do you and Dan mean when you say that the stories  
 should be
 expressed in the business domain rather than the UI domain?  (BTW, is
 there a link to a Dan North post abou that?)

 Sorry - there are two different threads going on about this topic
 right now - the other one is on the rspec-devel list and that was
 where Dan posted that statement:

 http://rubyforge.org/pipermail/rspec-devel/2007-November/004259.html

 Keep in mind that User Stories are oft described as a token for a
 conversation, and that even with acceptance criteria spelled out,
 whether the button says Create New Account or Enter is rarely of
 sufficient business value to express that in a story. That's the sort
 of detail that comes out when you say to your customer the entry form
 is done, why don't you come by so I can show it to you, as opposed to
 in the iteration planning meeting.

 In the end it really does boil down to what the customer feels is
 necessary in order to accept the software. If the customer really DOES
 care about what the button says, he or she may want that expressed in
 a story. But even then, saying And I press Create New Account still
 leaves things flexible enough so that you could be describing a web
 app, a GUI app, a touch-screen app, etc. The only thing this doesn't
 work for would be a command line app. So maybe And I tell the system
 to Create New Account would leave room for that as well. Or maybe,
 And I fold my arms and command the system to Create New Account. I
 kinda like that one!

 From my understanding you
 are saying that the steps that say user types in such and such and
 user hits the login button are too UI specific and don't really  
 have
 much to do with the business domain.  Is that correct?

 Unless the business IS software, like a text editor, yes.

 I think that this is a part of writing stories that I am somewhat
 struggling with, meaning how specific should these stories be in
 explaining the view?  At RubyConf during your presentation (great  
 job,
 BTW!) you mentioned how you like to spec out your views first.

 Ah - confusion. I DO like to spec my views first - when I get down to
 the Spec Framework.

 In our example at RailsConf EU, we talked about a Cup Tracker (as in
 Rugby, which was going on at the time). Take a look at the example
 story:

 http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter1/stories/plan_cup.rb

 This story really rides this whole line very nicely. We're describing
 software that presents a view of something abstract, and we do so with
 some detail about what it presents - but there is nothing in it that
 says when I click this button or when I enter this text.

 Now look at this version (same story, w/ the steps