running features organized into subdirectories separated
Joaquin Rivera Padron
I have started my project having all features living in the features/ directory. After my project grows beyond simplicity can manage I started organizing my features into features-subdirectories [1] BUT leaving my steps (for the moment?) in features/step_definitions maybe mostly because (e.g.) client_steps could be used in an admin feature
when runned all together everything ok, but when trying to do (e.g)
$ cucumber features/clients/XXX.feature
then cuke can find the unnested steps and mark them as unimplemented
so: how can I have organized features but unorganized steps? I could really save my time by delaying organizing the steps right now :-)
thanks in advance,
joaquin
[1] http://groups.google.com/group/cukes/browse_thread/thread/4ec4ad710c2bb111/bb998adf14107e84?lnk=gst&q=Question+regarding+detail+of+feature+and+organization+of+feature+files#bb998adf14107e84
--
www.least-significant-bit.com
aslak hellesoy
<joah...@gmail.com> wrote:
> hi there
> I have started my project having all features living in the features/
> directory. After my project grows beyond simplicity can manage I started
> organizing my features into features-subdirectories [1] BUT leaving my steps
> (for the moment?) in features/step_definitions maybe mostly because (e.g.)
> client_steps could be used in an admin feature
>
> when runned all together everything ok, but when trying to do (e.g)
>
> $ cucumber features/clients/XXX.feature
>
> then cuke can find the unnested steps and mark them as unimplemented
>
> so: how can I have organized features but unorganized steps? I could really
> save my time by delaying organizing the steps right now :-)
>
--require features
alternatively:
--require features/support --require features/step_definitions
--help for more
Aslak
> thanks in advance,
> joaquin
>
> [1]
> http://groups.google.com/group/cukes/browse_thread/thread/4ec4ad710c2bb111/bb998adf14107e84?lnk=gst&q=Question+regarding+detail+of+feature+and+organization+of+feature+files#bb998adf14107e84
> --
> www.least-significant-bit.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to
> cukes+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cukes?hl=en.
>
Matt Wynne
On 1 Feb 2010, at 12:40, aslak hellesoy wrote:
> On Mon, Feb 1, 2010 at 1:23 PM, Joaquin Rivera Padron
> <joah...@gmail.com> wrote:
>> hi there
>> I have started my project having all features living in the features/
>> directory. After my project grows beyond simplicity can manage I
>> started
>> organizing my features into features-subdirectories [1] BUT leaving
>> my steps
>> (for the moment?) in features/step_definitions maybe mostly because
>> (e.g.)
>> client_steps could be used in an admin feature
>>
>> when runned all together everything ok, but when trying to do (e.g)
>>
>> $ cucumber features/clients/XXX.feature
>>
>> then cuke can find the unnested steps and mark them as unimplemented
>>
>> so: how can I have organized features but unorganized steps? I
>> could really
>> save my time by delaying organizing the steps right now :-)
>>
>
> --require features
>
> alternatively:
> --require features/support --require features/step_definitions
>
> --help for more
>
> Aslak
Joaquin do you think it would have been less surprising if Cucumber
had looked for a 'features' folder in your current working directory
and automatically required it?
Also, do you think this proposed feature might have helped?
https://rspec.lighthouseapp.com/projects/16211/tickets/531-declarative-mechanism-for-expressing-dependencies-on-step-definitions
>
>> thanks in advance,
>> joaquin
>>
>> [1]
>> http://groups.google.com/group/cukes/browse_thread/thread/4ec4ad710c2bb111/bb998adf14107e84?lnk=gst&q=Question+regarding+detail+of+feature+and+organization+of+feature+files#bb998adf14107e84
>> --
>> www.least-significant-bit.com
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Cukes" group.
>> To post to this group, send email to cu...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> cukes+un...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/cukes?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en
> .
>
cheers,
Matt
Joaquin Rivera Padron
On 1 Feb 2010, at 12:40, aslak hellesoy wrote:
On Mon, Feb 1, 2010 at 1:23 PM, Joaquin Rivera Padron
<joah...@gmail.com> wrote:
hi there
I have started my project having all features living in the features/
directory. After my project grows beyond simplicity can manage I started
organizing my features into features-subdirectories [1] BUT leaving my steps
(for the moment?) in features/step_definitions maybe mostly because (e.g.)
client_steps could be used in an admin feature
when runned all together everything ok, but when trying to do (e.g)
$ cucumber features/clients/XXX.feature
then cuke can find the unnested steps and mark them as unimplemented
so: how can I have organized features but unorganized steps? I could really
save my time by delaying organizing the steps right now :-)
--require features
cool, that would be it. I can move on now :-)
Joaquin do you think it would have been less surprising if Cucumber had looked for a 'features' folder in your current working directory and automatically required it?
alternatively:
--require features/support --require features/step_definitions
--help for more
Aslak
Also, do you think this proposed feature might have helped?
https://rspec.lighthouseapp.com/projects/16211/tickets/531-declarative-mechanism-for-expressing-dependencies-on-step-definitions
yep, +1 here
thanks again,
joaquin
thanks in advance,
joaquin
[1]
http://groups.google.com/group/cukes/browse_thread/thread/4ec4ad710c2bb111/bb998adf14107e84?lnk=gst&q=Question+regarding+detail+of+feature+and+organization+of+feature+files#bb998adf14107e84
--
www.least-significant-bit.com
--
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to
cukes+un...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
cheers,
Matt
http://mattwynne.net
+447974 430184
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
--
www.least-significant-bit.com
Phillip Koebbe
I'm something of a control freak and a recovering perfectionist, meaning
that I like to have things *just* the way I want them and will often
change what I want when I realize that what I currently want isn't
perfect. It's a sad life, really, but it's one that I almost fully
embrace ;)
I have diverted from the default Cucumber scheme by creating the
following directory structure
RAILS_ROOT/cuke
RAILS_ROOT/cuke/features
RAILS_ROOT/cuke/steps
RAILS_ROOT/cuke/steps/shared
RAILS_ROOT/cuke/support
Each feature has a file that lives in cuke/features or in a subdirectory
of features. If, for example, I have a number of admin-related features,
I would put them in cuke/features/admin. Steps that belong to an
individual feature live in a file named according to the feature in
cuke/steps or the corresponding subdirectory (as in the admin example,
cuke/steps/admin). Any steps that are shared across features *in the
current project* live in cuke/steps/shared (the filename is not
important here, but it is usually 'shared', though you could separate
into 'client', 'payment', etc). Any step that I am able to abstract out
far enough that it is generic and can be used in any project I put in my
own library that lives in cuke/support. As an example, suppose my
feature is user_login.feature:
cuke/features/user_login.feature
cuke/steps/user_login_steps.rb
Obviously, Cucumber does not support this structure, so I had to write
my own script to require the necessary files and call cucumber. I follow
the same structure in all of my projects, so this control script lives
in /usr/local/bin. When it runs, it automatically requires everything in
cuke/support and cuke/steps/shared. I pass it a feature or a pattern to
match, and it makes a list of all the feature files that it thinks it
should run, then for each one, it looks for a corresponding step file to
require. I have added some support for tags as well. And since I use
Culerity/Celerity, the script also handles starting/stopping the
culerity server. As a bonus, I also threw in zeroing out the log files
at the beginning of each run so I could start with a clean log. With my
script, I can do this:
kuke user_login
or
kuke *login
if I have a user_login and an admin_login. If I have a number of
features in cuke/features/admin, I can do
kuke admin/*
or just
kuke
if I want to run all features in my project.
YMMV, but this works exceptionally well for me. I'd be happy to share my
script if you are interested in seeing it.
I guess I should say that this started as a way to have Cucumber more
aligned with RSpec, but it quickly became something else entirely. :)
Peace,
Phillip
Matt Wynne
Could you have a look at this ticket and see if there are any of your
ideas that could be incorporated into Cucumber? It sounds like your
script satisfied the same need as what I proposed in that ticket -
maybe between them we can come up with something great :)
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en
> .
>
cheers,
Phillip Koebbe
> ideas that could be incorporated into Cucumber? It sounds like your
> script satisfied the same need as what I proposed in that ticket -
> maybe between them we can come up with something great :)
>
> https://rspec.lighthouseapp.com/projects/16211/tickets/531-declarative-mechanism-for-expressing-dependencies-on-step-definitions#ticket-531-9
>
Hi Matt,
You can have a look at the script here
It might appear a bit convoluted at first, but I provided myself the
ability to do something like this:
kuke ~long_running_feature
or
kuke admin/*,~admin/messages
So I could run many features at one time while excluding some that I
know take a long time (or for whatever reason). And I can do the same
thing with tags (and not have to use @). But the way I use tags is a bit
different than the standard way, so this may not be useful to anyone
other than me. I use tags to number my scenarios so I can run one at a
time more easily. So I might want to run all of my scenarios in a
feature except for a couple, and so could do
kuke admin/messages ~12,~13,~14
I'm thinking about adding range support to make it easier
kuke admin/messages ~12-14
but I haven't felt like doing it yet.
If you see anything in there that you think might be helpful, feel free
to borrow it.
Peace,
Phillip
Andrew Premdas
Each feature has a file that lives in cuke/features or in a subdirectory of features. If, for example, I have a number of admin-related features, I would put them in cuke/features/admin. Steps that belong to an individual feature live in a file named according to the feature in cuke/steps or the corresponding subdirectory (as in the admin example, cuke/steps/admin). Any steps that are shared across features *in the current project* live in cuke/steps/shared (the filename is not important here, but it is usually 'shared', though you could separate into 'client', 'payment', etc). Any step that I am able to abstract out far enough that it is generic and can be used in any project I put in my own library that lives in cuke/support. As an example, suppose my feature is user_login.feature:
cuke/features/user_login.feature
cuke/steps/user_login_steps.rb
Obviously, Cucumber does not support this structure, so I had to write my own script to require the necessary files and call cucumber. I follow the same structure in all of my projects, so this control script lives in /usr/local/bin. When it runs, it automatically requires everything in cuke/support and cuke/steps/shared. I pass it a feature or a pattern to match, and it makes a list of all the feature files that it thinks it should run, then for each one, it looks for a corresponding step file to require. I have added some support for tags as well. And since I use Culerity/Celerity, the script also handles starting/stopping the culerity server. As a bonus, I also threw in zeroing out the log files at the beginning of each run so I could start with a clean log. With my script, I can do this:
kuke user_login
or
kuke *login
if I have a user_login and an admin_login. If I have a number of features in cuke/features/admin, I can do
kuke admin/*
or just
kuke
if I want to run all features in my project.
YMMV, but this works exceptionally well for me. I'd be happy to share my script if you are interested in seeing it.
I guess I should say that this started as a way to have Cucumber more aligned with RSpec, but it quickly became something else entirely. :)
Peace,
Phillip
Could you have a look at this ticket and see if there are any of your ideas that could be incorporated into Cucumber? It sounds like your script satisfied the same need as what I proposed in that ticket - maybe between them we can come up with something great :)
https://rspec.lighthouseapp.com/projects/16211/tickets/531-declarative-mechanism-for-expressing-dependencies-on-step-definitions#ticket-531-9
Matt Wynne
That's a really good point Andrew. I still think there is a use case,
particularly within a single team working on several projects or sub-
systems, where you want to be able to use the same language (and hence
the same step defs) across feature sets.
I would also personally prefer to see the webrat_steps.rb go into a
library, rather than having it be over-written every time we upgrade
cucumber.
Aslak Hellesøy
>> cuke/support. As an example, suppose my feature is
> or sub-systems, where you want to be able to use the same language
> (and hence the same step defs) across feature sets.
>
> I would also personally prefer to see the webrat_steps.rb go into a
> library, rather than having it be over-written every time we upgrade
> cucumber.
>
I think that should be an option (maybe the default). We could add an
--explode option to the generator so people who want the stepdefs in
their own codebase still have that option.
Aslak
byrnejb
On Feb 5, 7:03 am, Aslak Hellesøy <aslak.helle...@gmail.com> wrote:
>
> I think that should be an option (maybe the default). We could add an
> --explode option to the generator so people who want the stepdefs in
> their own codebase still have that option.
>
> Aslak
Just recall that some of us choose not to use the support/paths.rb and
therefore must modify the the two web_steps related to them.
I still believe that __/^I am on "(.*)"$/__ and __/^I go to "(.*)/__
are too greedy to be placed in a general library. The phrasing is
just too commonly used in features and these implementations either
consume or conflict with any local variation which tries to be more
specific.
Phillip Koebbe
> ideas that could be incorporated into Cucumber? It sounds like your
> script satisfied the same need as what I proposed in that ticket -
> maybe between them we can come up with something great :)
>
> #ticket-531-9
>
Just wanted to mention that I've been considering something akin to
your original idea in the ticket. Since my use of cucumber is
completely dependent on my kuke script (and even more so since I added
some logic for setting an environment variable to instruct culerity to
enable/disable javascript support), I've been toying with the idea of
adding a kuke.opts file in each project that would contain
instructions for where to find what and various things to instruct
kuke. As kuke has been growing, it seems to me that a project-specific
conf file is what I need to keep the script as clean as possible. If I
keep going as I have been, I'm going to be in a pickle when I decide
to change my scheme around (as I inevitably do).
Not sure this contributes much to a cucumber-specific resolution, but
I did want to say that I'm heading toward the same place you are, at
least in part.
Peace,
Phillip