[rspec-users] [ANN] Cucumber Textmate Bundle
ben at benmabey.com
Wed Sep 17 17:35:20 EDT 2008
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
>>>> 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:
>>>> 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
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?
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.
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.
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
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
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
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:
>> 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?
More information about the rspec-users