[rspec-users] [ANN] Cucumber Textmate Bundle
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
>>>>> 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?
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 --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:
>>> 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?
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users