Hi Glenn.<br><br><div class="gmail_quote">On Nov 8, 2007 4:01 PM, Glenn Ford <<a href="mailto:glenn@aldenta.com">glenn@aldenta.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It seems that what I'm coming to understand of the direction of this<br>story concept is that there is a lot of emphasis being put on ensuring<br>we keep things at the business level. I can appreciate the elegance<br>
of it certainly, but when I think of what I would really want to gain<br>from this story-based testing process, I feel like it cuts out room<br>for some really cool ideas. Maybe you can help me see where they<br>would fit.
<br><br>I have in mind a scenario where a customer says "I tried to log in and<br>it blew up!" I take what they say with a business perspective and<br>check my story and say "hey I've got a login story and it works" but
<br>that doesn't leave room for the fact that, slighty away from the norm<br>of the usual login procedure, this particular user clicked another<br>link in the middle of the process that changed some background<br>variable, breaking the process at the final login step. I would then
<br>want to write a story similar to the usual login, but with the ACTUAL<br>details of what the customer did to ensure I could duplicate, fix, and<br>then never have this problem creep up again.</blockquote><div><br>I completely agree.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> My story, in order to be<br>of use to me, would HAVE to have steps like "click this button"
<br>because, quite frankly, as a developer I find that's the sort of thing<br>that can break my code and so I would want a story to account for it.</blockquote><div><br>Yes, exactly. In this example, the UI domain <i>
is </i>the most useful domain to express the (bogus) behaviour, so it's the right thing to do. The scenario might be something like:<br><br><div style="margin-left: 40px;">Scenario: press the Explode button whilst filling in form
<br><br>Given I navigate to the <b>Submit order</b> page <i>[I'm loving these infix parameters!]</i><br>And I set first name to <b>Dan</b> and second name to <b>North</b><br>When I click the Explode button<br>Then nothing should happen
<br>And the current page title should be <b>Submit order</b><br></div><br>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)
<br><br>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.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>A user following my intended user-flow, then deviating in a way I<br>didn't predict. From the business end, they still followed the login
<br>process, they just had one little different quirk along the way.</blockquote><div><br>Yes, and it's that quirk <i>in this particular UI</i> that you want to capture with this scenario. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is there a way to get this kind of thing but still keep to the ideal<br>business perspective?</blockquote><div><br>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.
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Would I just simply "word" it in a way that the<br>simple little thing they did had a business description? Or is that
<br>an indication that I have stupid things on my page that shouldn't even<br>be an option? Or is there a "happy medium" here as well between<br>business and ui perspectives of stories?</blockquote><div><br>
See above - as long as you keep the distinction between domains when you are describing a scenario, you'll probably be ok. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888">Glenn</font></blockquote><div><br>Cheers,<br>Dan<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
<br></font><div><div></div><div class="Wj3C7c"><br>On Nov 8, 2007, at 6:58 AM, David Chelimsky wrote:<br><br>> On Nov 8, 2007 12:17 AM, Ben Mabey <<a href="mailto:ben@benmabey.com">ben@benmabey.com</a>> wrote:<br>
>> David Chelimsky wrote:<br>><br>> <snip><br>><br>>>> ... the philosohy that Dan is<br>>>> espousing: expressing stories in the business domain rather than the<br>>>> UI domain (btw Dan, that was brilliantly put).
<br>>> What exactly do you and Dan mean when you say that the stories<br>>> should be<br>>> expressed in the business domain rather than the UI domain? (BTW, is<br>>> there a link to a Dan North post abou that?)
<br>><br>> Sorry - there are two different threads going on about this topic<br>> right now - the other one is on the rspec-devel list and that was<br>> where Dan posted that statement:<br>><br>> <a href="http://rubyforge.org/pipermail/rspec-devel/2007-November/004259.html" target="_blank">
http://rubyforge.org/pipermail/rspec-devel/2007-November/004259.html</a><br>><br>> Keep in mind that User Stories are oft described as "a token for a<br>> conversation", and that even with acceptance criteria spelled out,
<br>> whether the button says "Create New Account" or "Enter" is rarely of<br>> sufficient business value to express that in a story. That's the sort<br>> of detail that comes out when you say to your customer "the entry form
<br>> is done, why don't you come by so I can show it to you," as opposed to<br>> in the iteration planning meeting.<br>><br>> In the end it really does boil down to what the customer feels is<br>> necessary in order to accept the software. If the customer really DOES
<br>> care about what the button says, he or she may want that expressed in<br>> a story. But even then, saying "And I press Create New Account" still<br>> leaves things flexible enough so that you could be describing a web
<br>> app, a GUI app, a touch-screen app, etc. The only thing this doesn't<br>> work for would be a command line app. So maybe "And I tell the system<br>> to Create New Account" would leave room for that as well. Or maybe,
<br>> "And I fold my arms and command the system to Create New Account." I<br>> kinda like that one!<br>><br>>> From my understanding you<br>>> are saying that the steps that say "user types in such and such" and
<br>>> user "hits the login button" are too UI specific and don't really<br>>> have<br>>> much to do with the business domain. Is that correct?<br>><br>> Unless the business IS software, like a text editor, yes.
<br>><br>>> I think that this is a part of writing stories that I am somewhat<br>>> struggling with, meaning how specific should these stories be in<br>>> explaining the view? At RubyConf during your presentation (great
<br>>> job,<br>>> BTW!) you mentioned how you like to spec out your views first.<br>><br>> Ah - confusion. I DO like to spec my views first - when I get down to<br>> the Spec Framework.<br>><br>> In our example at RailsConf EU, we talked about a Cup Tracker (as in
<br>> Rugby, which was going on at the time). Take a look at the example<br>> story:<br>><br>> <a href="http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter1/stories/plan_cup.rb" target="_blank">
http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter1/stories/plan_cup.rb</a><br>><br>> This story really rides this whole line very nicely. We're describing<br>> software that presents a view of something abstract, and we do so with
<br>> some detail about what it presents - but there is nothing in it that<br>> says "when I click this button" or "when I enter this text."<br>><br>> Now look at this version (same story, w/ the steps filled in):
<br>><br>> <a href="http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter4/stories/plan_cup.rb" target="_blank">http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter4/stories/plan_cup.rb
</a><br>><br>> Note how the implementations of the steps are starting to get into the<br>> views. That's where that level of detail starts to play out.<br>><br>> Now look at this:<br>><br>> <a href="http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter4/spec/views/cups/show.rhtml_spec.rb" target="_blank">
http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter4/spec/views/cups/show.rhtml_spec.rb</a><br>><br>> That spec was arrived at with the very granular red-green-refactor<br>> process of TDD with a focus, naturally, on behaviour, design and
<br>> documentation (It just occurs to me that behaviour, design and<br>> documentation are B, D and D - interesting ...).<br>><br>> Now some people look at that spec and scream "holy crap - look at all<br>
> the duplication - all that mocking - so brittle!." I won't disagree<br>> that there is lots of duplication with other parts of the system, a<br>> lot of mocking, and changes to the views would require changes to this
<br>> spec (brittle). And, looking back at this, I might want to break that<br>> spec up into more granular examples. While it speaks very well looking<br>> at the code, running it would only tell you that "/cups/show.rhtml
<br>> should display the chart."<br>><br>> But check this out! The implementation of that spec, with all that<br>> mocking, IS the spec for the controller and model. That single spec<br>> tells us about the structure that the model should expose (NOT the
<br>> actual structure necessarily - just what it should expose to things<br>> like views that want the models to be easy to use) and what the<br>> controller should provide for the view.<br>><br>> So this is all about discovery - starting from the outside and moving
<br>> in. Implementing the steps that describe domain concepts help us to<br>> discover some details of the views. Implementing the view specs help<br>> us to discover the services we want from our controller and the APIs
<br>> we want from our model. I find that to be very compelling.<br>><br>> <snip><br>><br>>> Where is the happy medium, in your opinion, between<br>>> keeping the stories concise and letting them drive every aspect of
<br>>> the<br>>> development? Maybe I am wrong in saying that the stories should<br>>> drive<br>>> EVERY aspect of the development?<br>><br>> Well, they should drive every aspect, but not directly. You're not
<br>> going to describe database table structure in your stories, but in the<br>> end those structures end up as they do because of the stories.<br>><br>>>>> The Selenium integration is also an interesting idea that you
<br>>>>> might want<br>>>>> to read about if you haven't seen this post. I'm still trying to<br>>>>> decided if using Selenium is worth the extra effort (my main goal<br>>>>> would
<br>>>>> be to test the JS during the acceptance tests)<br>><br>> <snip><br>><br>>>> Generally speaking, in-browser tests tend to be incredibly brittle<br>>>> and<br>>>> run dog-slow. They simply have no choice but to be tied directly to
<br>>>> low-level implementation details like html structure and element<br>>>> IDs.<br>>>><br>>>> So I'd recommend only testing what you absolutely must in-browser.<br>>>> But
<br>>>> given our ajax-laden world, "what you absolutely must" may well turn<br>>>> out to be a lot!<br>><br>> <snip><br>><br>>> I have heard that Selenium suites can become out of hand and end of
<br>>> being more hassle than what there worth. Thanks for the<br>>> recommendation,<br>>> I think that sounds like a sensible one.<br>>><br>>> Thanks for taking the time to discuss this,<br>
><br>> My pleasure!<br>><br>> Cheers,<br>> David<br>><br>>><br>>> Ben<br>> _______________________________________________<br>> rspec-users mailing list<br>> <a href="mailto:rspec-users@rubyforge.org">
rspec-users@rubyforge.org</a><br>> <a href="http://rubyforge.org/mailman/listinfo/rspec-users" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-users</a><br><br>_______________________________________________
<br>rspec-users mailing list<br><a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/rspec-users" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-users
</a><br></div></div></blockquote></div><br>