[rspec-users] How to write the very first example?

[Scott Taylor]

On Sep 29, 2007, at 5:43 PM, Matthijs Langenberg wrote:

> Many posts on this list are about using RSpec with Rails and that's  
> the way I'm also using RSpec all the time.
> Unfortunately there isn't that much info about using RSpec for  
> standalone Ruby projects.
>
> I must admit I'm really having a hard time writing the very first  
> example(s) for a fresh standalone Ruby project. I haven't really  
> got a clue where to start, how to call the first example and how to  
> describe it.
> I want to use the outside-in approach, but that suggests the first  
> example you write should specify the workings of the whole project,  
> right?
> I alway catch myself focusing on dependancies and start from the  
> inside instead of the outside. (if I implement this first, I can  
> use it as a building brick for that feature, and if that feature is  
> implemented I can work on that other feature.)
>
> So, where do I actually need to start?


I sympathize with your position.  I imagine it's much easier now that  
the story/rbehave stuff is around.

In the past what I've done is written a prototype (usually a  
functioning one) - and have done it code-first, with no tests  
whatsoever.  (I'm also thinking of Paul Graham's words - all large  
programs start as small programs/scripts).  Once I have that  
prototype, I rewrite the code, this time going test first, and making  
it Object Oriented.  If I ever need to refer back to that old code, I  
can, but, at the same time, now I have written something slightly  
different, which is architectured better, and has tests to back it up.

Just to give you an example of this, a few months ago I wrote a  
backup system.  The core of it was just using rsync - very much like  
a simple script.  But soon I wanted much more - backup deletion which  
would happen automatically, based on rules specified in a DSL.  So I  
rewrote the core of the system test first, and was then able to layer  
the rest of the features on top and around that.

Going on the 37 signals mantra: What is the most important feature of  
the system?  That's what you should be writing specs for.  They may  
happen to be quite high level - that's what your stories are for.   
Write one story (or a high level spec which you can mark as  
"pending"), and drill deeper into that, writing specs for the modules/ 
classes that it will take to make that initial story going.

Hope that helps,

Scott