Question regarding detail of feature and organization of feature files

[Jose]

I've been studying examples of features in preparation to apply them
in a Rails application. In all of the examples I've seen so far, I've
seen one feature per feature file. Also, the features are broad or
detailed.

What's the best way to organize feature files? For example, I have a
dashboard in my application. It will have broad features like
important tasks appear prominently on the page. It will have detailed
features like when I click on a button, details of the task are
revealed.

Do I put each feature in its own file? Should I organize them into
directories? Can I have multiple features in a single file?

The file organization seems important to me since, I expect I'll end
up with lots of them and I'll be needing to find features quickly for
my work and for presenting them to my client.

Hope my description is enough information.

Thanks in advance.

[Stephen Eley]

On Wed, Jul 15, 2009 at 10:54 AM, Jose<jo...@stat.ucla.edu> wrote:
>
> Do I put each feature in its own file?  Should I organize them into
> directories?  Can I have multiple features in a single file?

I've never tried putting multiple features into one file, but I would
suggest that a 1:1 correlation between features and files is a Very
Good Idea for maintainability and isolation of changes. It's the same
general principle that you see behind "one class per file." I can't
imagine what gains you'd see by putting a whole bunch of features in
one text file and having to scroll to navigate them. Put one feature
in each file and name the file for the feature.

Organizing them into directories by concept or functional are, though,
is no problem. (And also a good idea when the number of them starts
to grow.)

--
Have Fun,
Steve Eley (sfe...@gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

[byrnejb]

On Jul 15, 10:54 am, Jose <j...@stat.ucla.edu> wrote:

> What's the best way to organize feature files?  ...
> ... Do I put each feature in its own file?  Should I organize them into

> directories?  Can I have multiple features in a single file?
>

As Steve pointed out, one feature per file seems the optimal
arrangement, as this speeds locating and editing the feature and its
scenarios. As for directory structure, the deciding factor here is
your own answer to the questions: Where did I put that feature, and
why?

I am writing a fairly large dbms based system and so I find myself
using a directory tree that roughly parallels the Rails app directory
structure. The default features directory contains the sub-directories
app, bin, lib, step_definitions and support. These last two
directories belong to cucumber and contain the usual default files
together with my local customisation files, which I preface with
local_.

My app directory is further subdivided in to models and controllers
directories. The feature files are named after the respective model
or controller of primary interest, so I have things in features/app/
models like currencies.feature and clients.feature. If I have
multiple features for a single model or controller then I create a sub-
directory for that design element and place the related feature files
within, so features/app/models/currencies/*.feature is where I will
find all feature files relating to the currency model.

Higher level stuff, like authentication.feature, I keep either in the
features/app directory itself, or in a components directory just under
app. The choice between these two locations depends upon whether the
code I am doing the feature for is mainly mine, or just my glue to an
externally sourced gem or plugin, in which case I stuff my feature
into the components directory. Per cucumber convention, I keep all
the step files in separate sub-directories called step_definitions.

The thing to consider is how do you personally search for a particular
feature? How do you conceive of the parts of your system? If your
mental model of your project is MVC then my method seems to map well,
at least for me. If you see things as components, then perhaps a
directory breakout named for major subsystems works better for you.
In any case, dumping everything into features and features/
step_definitions does not seem a practical approach for anything
approaching a reasonable sized project.

A further consideration that I do not need to account for, but that
many others do, is whether in a multi-developer environment should
each have their own sub-trees for features and steps. Finally, there
are going to be cases where a feature is so tightly bound to more than
one discrete design element that wherever you put it, it is going to
seem to be in the wrong place when you next go to look for it.

HTH

[David Chelimsky]

Hi James,

This sounds like you're using Cucumber for more detail than is common.
Not saying it's wrong or right, but AFAIK in most cases folks don't
specify models, for example, with Cucumber, they do that with more
granular tools like RSpec, test/unit, shoulda, etc, and use Cucumber
for a higher level view of things (when I visit xxx view or screen,
etc).

Are you also using a more object-focused tool like RSpec, or are you
using Cucumber exclusively?

Cheers,
David

[Matt Wynne]

Yeah that sounds pretty different to any set-up I've heard of James!

We started using a top-level folder that was organised by user type

e.g.
features/user
features/visitor
features/admin

but we found that we'd start prefixing groups of feature files together:

e.g.

features/user/dashboard_activity_feed_of_artist_events.feature
features/user/dashboard_activity_feed_of_user_events.feature

...so we've started using more sub-folders within those user type
folders too.

I'm starting to wonder whether organising them around users was the
right move (sometimes users of different types use aspects of the same
feature), and we are considering flipping over to sub-folders per
'feature group' within the main features folder.

I'd definitely advise using no more than one feature per file. If you
get the hang of using Background[1], that can often give you a good
feel for when a feature file has grown too large - if a new scenario
doesn't really fit with the Background, consider breaking it out into
another feature file.

[1]http://wiki.github.com/aslakhellesoy/cucumber/background

cheers,
Matt

+447974 430184
ma...@mattwynne.net
http://mattwynne.net

[byrnejb]

On Jul 16, 10:04 am, David Chelimsky <dchelim...@gmail.com> wrote:
> Hi James,
>
> This sounds like you're using Cucumber for more detail than is common.
> Not saying it's wrong or right, but AFAIK in most cases folks don't
> specify models, for example, with Cucumber, they do that with more
> granular tools like RSpec, test/unit, shoulda, etc, and use Cucumber
> for a higher level view of things (when I visit xxx view or screen,
> etc).
>
> Are you also using a more object-focused tool like RSpec, or are you
> using Cucumber exclusively?

On Jul 16, 6:20 pm, Matt Wynne <m...@mattwynne.net> wrote:
>
> Yeah that sounds pretty different to any set-up I've heard of James!
>

Please bear in mind that I do not come from a OO programming
background; that for me, all of this, Ruby, Rails, OOP, ORM, RDBMS,
TTD, BDD, etc. was, until recently, simply words in a book, or a bunch
of books. I still work with a 4GL and several CODASYL DBMS every day.

This is to say that I have developed my own approach to the
organisation problems presented by BDD. While this seems to suffice
for my needs it may not scale well for use by large groups.

I have used RSpec in the past. I repeatedly attempted to make it work
for me, but somehow I could never get my head around what it was
doing. I tried to understand RSpec stories when they were first
introduced, could it actually be 2 years ago? Again, my want of
relevant background prevented me from understanding what evidently so
many others could see plainly. Then I ran into Cucumber, and the
mystery was revealed to me.

Perhaps it was just a coincidence, because beginning last November I
was at last sufficiently recovered to really put some serious effort
into our conversion project, but I think not. Cucumber's total
bifurcation between user request and developer implementation really
clarified things for me. It was then I could begin the painful
process of mastering both a new language and a new approach.

Those who are longtime members of the RSpec list may recall my first
attempts. My excruciatingly detailed "features" that were not features
at all, but a rather poor attempt at pseudo code. Gradually however,
with more than a few nudges from those with a deal more experience
than I, I acquired more and more knowledge and a few skills. I
believe that I have the gist of things now and that I have moved from
the consciously incompetent to the (cautiously) consciously competent
stage.

One of the things that I read in my early attempts to understand TDD
said, in effect, do not test code that you did not write. Now, at the
time this struck me as both rather obvious and rather obscure, since I
lacked the knowledge to know for certain that I really understood what
was written. After initially dealing with excessive detail in
cucumber I gradually came to a similar position; that basically, if it
is not manifested as a user consumable then it probably does not need
to be tested.

Now, I know that this is not true in an absolute sense. There are all
sorts of systems where the invisible workings are absolutely vital and
the visible result negligible. But, my environment is a commercial
system. Which, when reduced to its essentials, is nothing more than a
bunch of filing cabinets related to each other though a series of
lists, each of which is traversed in a more or less repetitive or
predicable manner. Sometimes one totals what is on a list, sometimes
one inserts something into a filing cabinet and records the fact on a
list, and sometimes one discards a file and removes it from a list.
The central facet of this is that that these lists are always driven
by and exposed to the user. The point is, in a commercial system,
there is precious little that is not presented as a user consumable at
some point.

So, to answer your question, I am testing with Cucumber exclusively at
the moment, save only those parts I had done previously in RSpec. So
far this decision, or rather development for I never consciously made
such a decision, seems to work well. Since I have relatively high
powered equipment to develop with, hitting the local postgresql
database for testing has not yet had a significant impact on run
times. No doubt this will change but for now it seems more economical
to just run against the dbms than to spend the effort to build mock
objects.

In any case, I retain some scepticism about the efficacy of mocking
dbms rows. Yesterday for instance, I encountered a strange situation
where a particular row, that should be returned by my class method
given the data it contained, was not returned and so my feature was
failing. After a long session with Cucumber, adding more detailed
steps (but not very many, just two in fact) I was able to trace the
problem back to snippet of SQL code that had its arguments
interpolated. The proximate cause of the bug was actually in
PostgreSQL v8.2 and was the result of an implicit cast of the
arguments by the dbms itself. If I had tested against a mock instead
of the dbms this bug, in all probability, would have lain silent for
years in the application code. Because if I wrote a mock then that
mock would give me what I expected the dbms to give me, which proved
rather different in the actual case.

As for specifying models in Cucumber, I do not, at least not in the
sense of laying out all of the columns and their default attributes.
However, I do drive the UI through Cucumber and there are few columns
that are not exercised by the UI. I also have a few class methods on
some models and this I also drive through Cucumber, as detailed
above. As I am approaching this development one user feature at a
time, and as so far each primitive feature seems to localise naturally
around one principal model, I find that the layout of features/app/
models keeps things nicely segregated for me. I can then do things
like cucumber -r features features/app/models/currency and get all of
the features relating principally to the currency model and avoid the
overhead of running all the rest. One can achieve the same thing with
file name conventions but I just find my approach maps more naturally
to the Rails conventions and therefore I can more readily find things
when I have a problem with a particular model or controller.

I find that I have written more than I should have, so I will stop. I
crave your indulgence.