Thanks for clearing things up Pat!<div>I'll give the story stuff I try, I haven't looked at it yet.</div><div><br class="webkit-block-placeholder"></div><div>Does this actually mean I need to start describing some stories, then start with writing the examples/code for the first story by using mock objects for every layer?
</div><div>Do I eventually need to replace all the mocks by real objects?</div><div>And is it bad to do partially stubbing on objects, or does this indicate an object should provide more information about its state?</div>
<div><br class="webkit-block-placeholder"></div><div>For instance, take a look at this pastie <a href="http://pastie.caboo.se/102174">http://pastie.caboo.se/102174</a>, is this a good way to write an example for a behaviour or am I taking a wrong approach?
</div><div><br class="webkit-block-placeholder"></div><div>I feel the need for some small, simple, clean example programs, to take a look through.</div><div>Maybe, I just need to put my current pet project online and let people shoot at it.
</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>- Matthijs </div><div><br class="webkit-block-placeholder"></div><div><br><div><span class="gmail_quote">On 9/30/07,
<b class="gmail_sendername">Pat Maddox</b> <<a href="mailto:pergesu@gmail.com">pergesu@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 9/29/07, Matthijs Langenberg <<a href="mailto:mlangenberg@gmail.com">mlangenberg@gmail.com</a>> wrote:<br>> Many posts on this list are about using RSpec with Rails and that's the way<br>> I'm also using RSpec all the time.
<br>> Unfortunately there isn't that much info about using RSpec for standalone<br>> Ruby projects.<br><br>I don't think that matters much, the principles are the same. You<br>write stories for features, and write specs to drive object
<br>implementation. In fact I would say that Rails presents some unique<br>challenges for BDDing, and that a "pure" ruby project is easier!<br><br>> I must admit I'm really having a hard time writing the very first example(s)
<br>> for a fresh standalone Ruby project. I haven't really got a clue where to<br>> start, how to call the first example and how to describe it.<br><br>Begin at the beginning :P<br><br>There are a couple approaches. First thing I would do is write a
<br>story for one feature you want in the system. Having that story means<br>that you stay focused on one particular task and building the<br>infrastructure that will be used. I actually wrote a blog post a<br>while back on what I call "design deep, not wide" [1]
<br><br>On a simpler level, stories represent real progress. When you're done<br>with a story you should have actual value, and that is fulfilling and<br>motivating.<br><br>Also, you can start with smaller stories and build out from there. In
<br>Dan North's article about introducing rbehave [2] he works with simple<br>objects instead of a full application stack like you might in Rails.<br>When I first read it, I thought a standard spec might be more<br>appropriate. Once it hit me though (which was a couple months later),
<br>I fell in love with that approach.<br><br>To give you an idea, here's the starting code:<br><br>Story "transfer to cash account",<br>%(As a savings account holder<br> I want to transfer money from my savings account
<br> So that I can get cash easily from an ATM) do<br><br> Scenario "savings account is in credit" do<br> Given "my savings account balance is", 100<br> Given "my cash account balance is", 10
<br> When "I transfer", 20<br> Then "my savings account balance should be", 80<br> Then "my cash account balance should be", 30<br> end<br><br> Scenario "savings account is overdrawn" do
<br> Given "my savings account balance is", -20<br> Given "my cash account balance is", 10<br> When "I transfer", 20<br> Then "my savings account balance should be", -20
<br> Then "my cash account balance should be", 10<br> end<br>end<br><br>Eventually he sticks objects in there as he implements them, but at<br>least at the very beginning there's no code to speak of. It's just a
<br>user story. The beauty of it is that all you're doing is specifying<br>acceptance criteria - what it means to be "done." One scary part of<br>doing lower level specs is on some level you're designing code without
<br>any real sense of direction. You might not necessarily know what<br>objects you need. While specs are excellent for discovering the<br>behavior of objects, as far as what operations they perform and<br>interactions they have, they don't do much to help with the desired
<br>behavior of the system.<br><br>So, basically, writing stories forces you to think about what you want<br>to achieve, and gives you a clear way to measure progress. You know<br>where you want to end, and you know all the steps it takes to get
<br>there, and that gives you the knowledge of where to start.<br><br>> I want to use the outside-in approach, but that suggests the first example<br>> you write should specify the workings of the whole project, right?
<br>> I alway catch myself focusing on dependancies and start from the inside<br>> instead of the outside. (if I implement this first, I can use it as a<br>> building brick for that feature, and if that feature is implemented I can
<br>> work on that other feature.)<br><br>This is where mock objects yield their greatest benefits. A lot of<br>people think mock objects are good only for isolating expensive<br>resources, but they're fantastic in allowing you to design well in
<br>chunks. For example, something as simple as:<br><br>customer.place_order some_item, 12<br><br>Will require that I have a customer class, a place_order method, an<br>item class, and probably an order class somewhere. I'm adding a
<br>little feature, and all of a sudden I have to implement all these<br>classes, at least in bits, and because I'm only handling a little bit<br>of the behavior I don't have any idea how they're going to be used in
<br>other parts of the system. It's scary because there's more pressure<br>to get it right the first time.<br><br>mocks, otoh, allow you to defer all of that until later. When working<br>on a feature, I can concern myself only with that feature and not
<br>worry about all the plumbing that it may need. A couple things happen<br>there<br><br>1. I tend to end up with a clean, layered architecture. This happens<br>because I'm only working on one layer at a time. When I'm bouncing
<br>back and forth between layers, I have to be extra mindful of what I'm<br>dealing with, otherwise stuff that should be in one layer creeps into<br>another and now I've got a muddled, difficult to understand design.
<br>2. My life is easier! With mocks, I can isolate my thinking to a<br>certain level or chunk of the code. Instead of pushing and popping<br>all kinds of stuff on my mental stack, I limit the number of little<br>things I need to think about at one time. I wasn't blessed with
<br>unlimited brain space, so that's a huge win for me. It also creates<br>extra room to think about what I'm doing at a higher level and keep<br>everything in perspective.<br><br>It's interesting, because your questions really boil down to being
<br>overwhelmed with what you have to do. It's a feeling I know all too<br>well. Fortunately RSpec provides two tools that do a fantastic job in<br>easing the uncertainty. First you have user stories which help give
<br>you direction in the project. You know what you want to get done,<br>have a good measure of progress as you implement it, and finally have<br>a clear understanding of when you've completed it. On a lower level,<br>
mock objects help keep your thinking focused instead of running off in<br>all different directions writing the all the infrastructure that it<br>may take to write one line of code. You become less likely to code<br>yourself into a corner, and you keep your mental stack in check.
<br><br>I hope that was helpful. I completely understand sitting at the<br>keyboard wondering just what the hell I should be doing. I've found<br>that RSpec helps me out a great deal both in terms of capturing<br>desired business outcomes and in implementing the code to achieve
<br>them. It can take a while to really get it, but you may come to find<br>that once you do you're hooked.<br><br>Pat<br><br>[1] <a href="http://evang.eli.st/blog/2006">http://evang.eli.st/blog/2006</a>/12/18/design-deep-not-wide
<br>[2] <a href="http://dannorth.net/2007/06">http://dannorth.net/2007/06</a>/introducing-rbehave<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">http://rubyforge.org/mailman</a>/listinfo/rspec-users<br></blockquote></div><br></div>