[rspec-devel] directory structure/naming

David Chelimsky dchelimsky at gmail.com
Mon Sep 22 22:03:18 EDT 2008

On Mon, Sep 22, 2008 at 9:00 PM, Ben Mabey <ben at benmabey.com> wrote:
> David Chelimsky wrote:
>> On Mon, Sep 22, 2008 at 8:36 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>>> On Mon, Sep 22, 2008 at 12:30 PM, linojon <linojon at gmail.com> wrote:
>>>> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>>>>> David Chelimsky wrote:
>>>>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>>>>> examples" as the proper names for talking about ... well ... features,
>>>>>> scenarios and code examples. If you don't know what I mean by those
>>>>>> things, then maybe we still have a problem, but I'm guessing most of
>>>>>> you do.
>>>>>> So I'm thinking of a new directory structure:
>>>>>> app-root
>>>>>>> behaviour
>>>>>>>> code-examples
>>>>>>>> features
>>>>>> I've always wanted to group these things together, but
>>>>>> behaviour/examples never worked for me as behaviour/code-examples
>>>>>> does.
>>>>>> WDYT?
>>>>>> _______________________________________________
>>>>>> rspec-devel mailing list
>>>>>> rspec-devel at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>>  I really like the idea of grouping the two in a 'behaviour' directory.
>>>>> I tend to have helpers that I use in both my examples and my features so
>>>>> placing them both in the same directory makes sense from an organization
>>>>> point of view.  (Plus, I really like having the name be 'behaviour'--
>>>>> even if it is spelled wrong. :p)
>>>>> I agree that the term code-examples is far less ambiguous than just
>>>>> plain 'examples'.  The fact that we refer to them as examples and even
>>>>> rspec internally treats them as examples does beg the question on how we
>>>>> got stuck with specs in the first place.  While I like the idea of
>>>>> code-examples I think that will be a much harder transition because so
>>>>> many people are used to the name 'spec' at this point (including
>>>>> myself.)  What is the main argument for ditching spec in favor of
>>>>> code-example?  Less baggage?
>>>>> -Ben
>>>> features is to scenarios
>>>> as
>>>> specs is to examples
>>>> therefore the directories:
>>>> behaviour
>>>>        features
>>>>        specs
>>>> besides, i like less typing
>>>> :)
>>> Have we learned nothing from prioritizing the number of characters
>>> over a meaningful name? :)
>>> Any good shell will tab auto-complete anyways, and in an actual IDE
>>> you almost never have actually type in the name of the directory
>>> unless you're creating it.
>>> I like:
>>> behaviour
>>>   examples
>>>   features
>>> I think "code" communicates poorly. I like "code-examples", but I
>>> think if we drop "code" the same intent is expressed. I know that like
>>> "specs" whatever becomes convention will be cemented in everyone's
>>> heads very shortly. But while we're trying to get the words right,
>>> let's try to get the words right.
>> Agreed on the goal. I think the problem we have to solve is to come up
>> with words that reveal the differences between examples of features
>> and examples of code.
>> The problem I have with 'examples' by itself is that scenarios are
>> examples too, just at a higher level.
>> Also, examples appear in many, many libraries, and in most cases ... I
>> don't think that word means what you think it means ... at least not
>> in our context.
>> The reason I like 'features' and 'code' is that what we've got are
>> examples of features and code ;)
>> I'm not sold on the 'code' idea, but so far it speaks better to me
>> than any other.
>> More thoughts?
> How about object-examples?  It seems like the example framework is more
> geared toward, and is used more, on the object level so maybe that
> naming would reinforce that.  That could be a good or bad thing... Just
> thought I would throw that out there.

We've certainly slung around the name "object specification framework"
before, so "object example framework" could work ... in theory.

More voices?

> -Ben

More information about the rspec-devel mailing list