On Wed, Sep 17, 2008 at 11:35 PM, Ben Mabey <[EMAIL PROTECTED]> wrote: > aslak hellesoy wrote: >> On Wed, Sep 17, 2008 at 10:56 PM, Ben Mabey <[EMAIL PROTECTED]> wrote: >> >>> aslak hellesoy wrote: >>> >>>> On Wed, Sep 17, 2008 at 8:42 PM, Ben Mabey <[EMAIL PROTECTED]> 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. 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
