[rspec-users] [ANN] Cucumber Textmate Bundle

Ben Mabey ben at benmabey.com
Wed Sep 17 19:14:29 EDT 2008


aslak hellesoy wrote:
> 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.
>
>   

Ok, nm, I thought you had to list each file individually.
>> 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.
>
>   
Yeah, I agree with that.  I will wait on the bundle implementation until
the cucumber command has been modified.

I've added a ticket:
http://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/12-add-profile-tag-to-cucumber-bin-with-yml-config
>> 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.
>   


The only value would be in combining both runs into a single report. 
Not the most important thing but it would be a nice to have.

> Aslak
>
>   
>> 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
>>
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>   



More information about the rspec-users mailing list