[rspec-devel] Game of Life questions

David Chelimsky dchelimsky at gmail.com
Tue Aug 28 14:47:42 EDT 2007


On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > > First of all, big kudos to Dan and David for making RBehave part of
> > > > > RSpec. This kicks ass.
> > > >
> > > > Mostly Dan - I just helped when he got stuck.
> > > >
> > > > > I'm finally taking a closer look at the new story runner and the
> > > > > examples. These are my observations as a newcomer. I'm not complaining
> > > > > - just pointing out things I think should be fixed - before I go ahead
> > > > > and fix some of it myself:
> > > > >
> > > > > 1) It was hard to figure out how to run the game of life example.
> > > > > First I looked for a Rake task and found none. Then I looked for
> > > > > instructions in a README and found none.
> > > >
> > > > This is all stuff we need to do, but keep in mind this is not a release yet.
> > > >
> > > > > Then I went online and David
> > > > > told me I had to run the everything.rb file. That works ok, but I
> > > > > think we should come up with a more idiomatic way to run things.
> > > >
> > > > Agree. Given the discussions we've been having recently about bridging
> > > > the RSpec/Test::Unit gap, we should have a single command that can
> > > > field stories, specs and tests.
> > > >
> > > > >
> > > > > 2) I stumbled across .story files. Because of the special file
> > > > > extension my initial hunch was that these are special files that the
> > > > > behaviour runner knows how to parse and "execute". Then I realised
> > > > > this is not the case. So I assume it's just leftovers, in which case I
> > > > > think it should be moved to a different directory (docs?), given a new
> > > > > file extension or deleted altogether. Same goes for the stores.txt
> > > > > file.
> > > > >
> > > > > 3) The file structure feels a little unusual. For example, it's common
> > > > > practice to have foo.rb as a sibling to the foo/ directory, but the
> > > > > stories.rb file is a child, not a sibling. Further, there is no lib
> > > > > folder for the code. Small things, but we should fix it. I think the
> > > > > best is to move the game of life up under trunk or at least make it a
> > > > > sibling of examples, not a child.
> > > >
> > > > +1 for cleaning this up. Not sure about where the example should go. I
> > > > think it's going to take some playing around for us to figure out how
> > > > projects should be structured now that we've got the two tool sets
> > > > merged. In the game-of-life example, we've got:
> > > >
> > > > project/behaviour/examples
> > > > project/behaviour/stories
> > > >
> > > > I like that, though we still need to get the name right for what we've
> > > > called specs and examples. Thinking about how this stuff works
> > > > together, one idea is:
> > > >
> > > > project/behaviour/objects
> > > > project/behaviour/stories
> > >
> > > I assume that is for a gem/regular ruby app. I like that structure.
> > >
> > > But what would the structure be in a Rails app?
> > >
> > > project/behaviour/models
> > > project/behaviour/controllers
> > > project/behaviour/views
> > > project/behaviour/helpers
> > > project/behaviour/objects # this is for lib - following same naming
> > > convention as for "gems"
> > > project/behaviour/stories
> >
> > For me, models, controllers, views, and helpers roll up under objects.
>
> I agree, but I don't want to have RAILS_ROOT/behaviour/objects/models
> - because that's too deep...

I agree, though then we should abandon the name objects in this case:

project/behaviour/controllers
project/behaviour/helpers
project/behaviour/lib
project/behaviour/models
project/behaviour/stories
project/behaviour/views

I think that's a bit confusing. It also doesn't map well w/ the rails
structure because it implies everything is at one level, but models
are below app, while lib is at the root. And then the stories
directory becomes confusing as well - it doesn't map to anything
specific in the app. So maybe we should do something like:

project/behaviour/controllers
project/behaviour/helpers
project/behaviour/lib
project/behaviour/models
project/behaviour/views

project/stories

WDYT?

>
> Aslak
>
> > There's always two levels of examples: story and everything else - I'm
> > saying everything else is objects, but it could be something else.
> > How's that for clarification?
> >
> > > ?
> > > >
> > > > I kind of like that, but I'm not sold. Thoughts?
> > > >
> > >
> > > It's good enough for me, but I'm cheap
> > >
> > > Aslak
> > >
> > > > David
> > > >
> > > > >
> > > > > Let me know what you think,
> > > > >
> > > > > Aslak
> > > > > _______________________________________________
> > > > > rspec-devel mailing list
> > > > > rspec-devel at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > > >
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list