aslak hellesoy wrote: > 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. > >
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@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >> > _______________________________________________ > 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
