[rspec-users] [ANN] Cucumber Textmate Bundle

aslak hellesoy aslak.hellesoy at gmail.com
Wed Sep 17 18:42:32 EDT 2008

On Wed, Sep 17, 2008 at 11:35 PM, Ben Mabey <ben at benmabey.com> wrote:
> aslak hellesoy wrote:
>> On Wed, Sep 17, 2008 at 10:56 PM, Ben Mabey <ben at benmabey.com> wrote:
>>> aslak hellesoy wrote:
>>>> On Wed, Sep 17, 2008 at 8:42 PM, Ben Mabey <ben at benmabey.com> wrote:
>>>>> Hey all,
>>>>> I am in the process of porting my RSpec Story Textmate bundle over to
>>>>> Cucumber.
>>>>> So far I have the syntax highlighting, file switching, and running of
>>>>> the features and single scenarios done.  So not all the functionally is
>>>>> ported yet and it has some rough edges but I think it is ready to be
>>>>> used/tested by more than just me. :)
>>>>> You can get it here:
>>>>> http://github.com/bmabey/cucumber-tmbundle/
>>>>> Please read the README as it talks about avoiding RSpec Story bundle
>>>>> collisions and how to run features.
>>>> Thanks a ton for making this, Ben. A couple of questions:
>>>> * What do you think about making it run bin/cucumber instead of rake?
>>> The advantage of using rake is that it gives a lot more flexibility to
>>> the developer as far as what step files are being required, etc.  In my
>>> case for example I have two rake tasks.  One that loads up an
>>> environment for testing JS parts of my web app.  The other task loads
>>> the the standard rails story world and webrat.  The problem I see with
>>> going with the straight bin command is that the bundle would have no way
>>> of knowing which files to require and which ones not to...  We could
>>> solve that with additional conventions and/or declaring more comments in
>>> the features about it's dependencies.  I'm totally fine with changing it
>>> if you have a good idea on how to solve the dependency problem that I
>>> have explained.
>> Rake can be slow to fire up, so I like to have the raw commandline.
>> What if cucumber could look for a cucumber.yml file that lookes
>> something like the following?
>> ---
>> default: rails
>> rails: --require features/steps/common --require features/steps/rails
>> watir: --require features/steps/common --require features/steps/watir
>> And then be able to run features like this:
>> cucumber --profile watir # Runs all watir features
>> cucumber # Runs all rails feature
>> WDYT?
> I like where you are going with this.  That would be a lot faster than
> rake doing a FileList too...
> So, in the feature that is a watir one would they just add a comment
> saying "# profile: waitir" or something like that?

I prefer to associate the profile with a cucumber run. It should be
able to run a feature with different profiles. Each profile can list
what features to include.

> We could actually have rake generate that yaml file for us based off of
> glob patterns since I can imagine those lines could grow very long and
> would be tedious to maintain by hand.

Why would they be long? It's usually just a folder name or two.
Cucumber expands folders to files internally.

> I'll think about it for a couple of days before I implement it to see if
> I can think of anything else, and maybe someone else would like to chime
> in on the matter.

You mean implement it in Cucumber? This is where the interpretation of
cucumber.yml should sit.

> This is somewhat OT but in regards to your "cucumber # Runs all rails
> feature " line.. One problem I have had a hard time overcoming with
> cucumber is how to run all of my stories together.  Meaning, for my

cucumber folder_name

(cucumber --help mentions this)

> watir env I may be creating a new browser object and doing things to the
> database in my Before and After blocks that I don't want/need to do when
> I run my standard rails stories.  Because of that and the fact that

What I do is to run cucumber twice. Once with features using standard
webrat/rails stuff and once with features using watir (we use this for
some ajax stuff). Then store results in two different files.

> cucumber in a way treats the entire process as the world it runs in it
> doesn't seem like you can  run very different types of features in the
> same process... Am I correct in saying that when environment s are very
> different unique processes are required to run them separately?  Like I

Yep. I don't see much value in combining different environments into one run.


> said, this is more of an aside and not relevant to the bundle.
>>>> * How can we make it play nice with the cucumber-supported languages?
>>> Hmm.. I think we could easily modify the bundle's syntax.. yeah.. this
>>> is what I came up with for the plaintext features syntax:
>>> http://github.com/bmabey/cucumber-tmbundle/commit/f695beb6bb1b6d3a2080b84e2b977f24f35431f2
>>> The file is getting pretty ugly however.  I think a better solution
>>> would be for the bundle's syntax files to be generated off of your
>>> languages.yml file.  I can investigate this latter as I think that would
>>> be a much better solution going forward.  Could we add Feature and the
>>> narrative translations to the languages.yml file as well?
>> We could, but I'm a bit reluctant as Cucumber itself doesn't care what
>> you write before the first scenario. What the hell, let's add it
>> anyway - it's good for the bundle and it's what we want people to use
>> ;-). I'll add it.
> Instead of stuffing it all in lanuages.yml maybe a new narratives.yml
> could be created?
> Ben
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list