Re: [rspec-users] Cucumber: Fix for Textmate syntax highlighting
I've added Given/When/Then as valid methods to take regexp as an argument to my Ruby.tmbundle, if its helpful (via bjeanes) http://github.com/drnic/ruby-tmbundle Commit: http://github.com/drnic/ruby-tmbundle/commit/2cff40d43dd65aad3d8cd050654823db6d7517cb Cheers Nic On Nov 15, 2:13 am, Ashley Moran wrote: > On Nov 14, 2008, at 3:25 pm, Matt Wynne wrote: > > > It's been bugging me for a while that a lot of the regular > > expressions in my step matchers look ugly inTextMatebecause it > > doesn't recognise them. > > > I patched the Ruby tmbundle with a fix. If this bugs you too, you > > can pull down my Ruby.tmbundle from here: > >http://github.com/mattwynne/textmate-bundles/tree/master > > > Or has somebody already solved this problem some other way? > > I've always stuck %r in front of the regex: > > Given %r/blah/ > > But I'd prefer a better fix! > > Ashley > > --http://www.patchspace.co.uk/http://aviewfromafar.net/ > > ___ > rspec-users mailing list > rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber fat client
Why not make a web client that manipulates git based projects in the background? I've been messing around with Grit and doing things like this lately for http://rdocul.us a site I run and it is very easy to do. If everything is in a standard location you could just add a project via an administrative page and it would be cloned in the background, then they could: browse all specs (just a filesystem listing) edit and save specs (git add, commit, push) look at a history on a given spec (log) look at the history of all changes to the specs (log on a path) merge changes / conflicts the only thing that would be hard at all would be the conflict resolution from if/when a normal git user update a spec. -Mike Matt Wynne wrote: On 9 Dec 2008, at 09:43, aslak hellesoy wrote: Hi folks, Cucumber has become popular a lot quicker than I had anticipated. Still, with its plain text nature it is still limited to programmers (in most teams). I want to close the gap between customers/product owners/business analysts and programmers, and I'm convinced that a fat client is needed to achieve this. Something that lets people browse, edit and run features inside a friendly user interface. So I'm asking you - what would this user interface be like? How do people want to access it and use it? We have a person filling the 'Product Owner' role who is completely non-technical. I think it would be nice if there was a way for her to be able to do this: * fire up the client * choose 'open project' * enter the URL to the git repo where the project lives * then see a nice overview of all the features * be able to print off features for taking to meetings, reading on the train etc, nicely formatted * be able to edit features and easily push the changes back to the git repo To me, this is more important than being able to run them. I don't think non-techie users need to be able to run features as they won't be able to do anything about it when they inevitably fail. I also hate the idea of having to set up Ruby, gems etc on a non-techie person's computer. It's better, IMO, if the tool makes it easy for them to push their changes into a git repo where they can either be swept into the main dev fork / branch, or automatically run using CI, et etc. So that's where I think the focus of such a tool should be - browsing, reviewing and editing features rather than executing them, and with some SCM integration to make all that easier for non-techies. I do think that eventually the ability to run features will become important too, but I would like to see this side of the problem solved first. Obviously there's a dependency on git in what I'm suggesting, but I'm sure it would be easy enough to plug in other SCMs if that was popular enough. Matt Wynne http://blog.mattwynne.net http://www.songkick.com ___ 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
Re: [rspec-users] Reuse of Cucumber Features
Hi Steve, I likely would only write two scenarios, one for a valid date and one for an invalid one. Then I would write object-level specs to determine what a valid date is. Extract this to a validator that you can reuse throughout your model. If it's important that you write features for each potential invalid date format (because you want to communicate them with the customer) then I would write a feature file similar to what you show...but it would be focused only on the date, I wouldn't mention patients or incidents at all. Date entry seems to be an important concept in your application, so I would write one feature that specifies how I expect date entry to work, and then I can just write valid/invalid dates for patient and incident features. Same idea as the first paragraph, but using features instead of specs. Pat "Steve Molitor" writes: > Thanks -- that gets me closer. Here's an example. Let's say I have two > features, 'Create new patient' and 'Create new incident'. To > create a new patient you have to enter a valid birth date. To create a new > patient you must enter a valid birth date. To create a new > incident you must enter a valid incident date. The rules for date entry are > the same: > > Feature: Date entry > > Scenario: Invalid month > When I fill in the date value with "13/01/2000" > I should see "Invalid date..." > > Scenario: Invalid year (not 4 digits) > When I fill in the date value with "13/01/00" > I should see "Invalid date..." > > Scenario: Separate with slashes (ok) > When I fill in the date value with "01/13/2000" > I should see "valid date..." > > Scenario: Separate with dashes (ok) > When I fill in the date value with "01-13-2000" > I should see "valid date..." > > etc > > Given the above, how should I write the 'create new patient' and 'create new > incident' features? I don't want to copy and paste all the > date related scenarios, but I do want to specify (and test) that the patient > birth date and incident date fields conform to the general date > rules. Here's how the 'create new patient' and 'create new incident' > features would look with some copy and pasting: > > Feature: Create new Patient > > Scenario: Enter invalid birth date > Given I fill in "birth date" with "13/01/2000" > And I fill in "patient name" with "Sam Smith" > When I press "Save" > I should see "Invalid birth date '13/01/2000'" > > Scenario: Enter valid birth date, valid name > Given I fill in "birth date" with "01/13/2000" > And I fill in "patient name" with "Sam Smith" > When I press "Save" > I should see "Patient Created Successfully" > > Scenario: Enter valid birth date with dashses. > --- > > Feature: Create new Incident > > Scenario: Enter invalid incident date > Given I fill in "incident" with "13/01/2000" > And I fill in "supervisor" with "Sam Smith" > When I press "Save" > I should see "Invalid incident date '13/01/2000'" > > Scenario: Enter valid incident date, valid supervisor > Given I fill in "incident date" with "01/13/2000" > And I fill in "supervisor" with "Sam Smith" > When I press "Save" > I should see "Incident Created Successfully" > > Scenario: Enter valid incident date with dashes > - > > Am I making sense? I want to specify the date in the features, as there may > be extra requirements like birth dates can not be in the future > in addition to the generic date requirements. And I want to validate that > the form checks for valid dates, displays the appropriate error > message when invalid, and uses the common rules for parsing. But I don't > want to copy and paste those scenarios in every feature. I think > reusing steps as you mention is probably the solution but I'm stuck on how to > word it and put it together in my case. > > Steve > > On Sun, Dec 14, 2008 at 8:41 AM, Matt Wynne wrote: > > On 13 Dec 2008, at 20:58, Steve Molitor wrote: > > What's the best way to handle a requirement that shows up as a > sub-requirement requirement in other features? For example let's say > users can enter dates in various forms throughout my application. > There is one set of global rules specifying the formats in which > dates may be entered, and how they are interpreted. I put that in > one feature. In various other features, like 'Create new > patient', one can enter dates, like the patient's birth date. I want > to do something like 'and the date entry shall follow the > normal rules' but I'm not sure how to do that in an example driven > way, without copying and pasting from other features. > > Does my question make sense? Any suggestions? > > Do you know that you can call steps within steps? > http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/ > > Is that what you're looking for? > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com >
Re: [rspec-users] Cucumber fat client
On 9 Dec 2008, at 09:43, aslak hellesoy wrote: Hi folks, Cucumber has become popular a lot quicker than I had anticipated. Still, with its plain text nature it is still limited to programmers (in most teams). I want to close the gap between customers/product owners/business analysts and programmers, and I'm convinced that a fat client is needed to achieve this. Something that lets people browse, edit and run features inside a friendly user interface. So I'm asking you - what would this user interface be like? How do people want to access it and use it? We have a person filling the 'Product Owner' role who is completely non-technical. I think it would be nice if there was a way for her to be able to do this: * fire up the client * choose 'open project' * enter the URL to the git repo where the project lives * then see a nice overview of all the features * be able to print off features for taking to meetings, reading on the train etc, nicely formatted * be able to edit features and easily push the changes back to the git repo To me, this is more important than being able to run them. I don't think non-techie users need to be able to run features as they won't be able to do anything about it when they inevitably fail. I also hate the idea of having to set up Ruby, gems etc on a non-techie person's computer. It's better, IMO, if the tool makes it easy for them to push their changes into a git repo where they can either be swept into the main dev fork / branch, or automatically run using CI, et etc. So that's where I think the focus of such a tool should be - browsing, reviewing and editing features rather than executing them, and with some SCM integration to make all that easier for non-techies. I do think that eventually the ability to run features will become important too, but I would like to see this side of the problem solved first. Obviously there's a dependency on git in what I'm suggesting, but I'm sure it would be easy enough to plug in other SCMs if that was popular enough. Matt Wynne http://blog.mattwynne.net http://www.songkick.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Reuse of Cucumber Features
Thanks -- that gets me closer. Here's an example. Let's say I have two features, 'Create new patient' and 'Create new incident'. To create a new patient you have to enter a valid birth date. To create a new patient you must enter a valid birth date. To create a new incident you must enter a valid incident date. The rules for date entry are the same: Feature: Date entry Scenario: Invalid month When I fill in the date value with "13/01/2000" I should see "Invalid date..." Scenario: Invalid year (not 4 digits) When I fill in the date value with "13/01/00" I should see "Invalid date..." Scenario: Separate with slashes (ok) When I fill in the date value with "01/13/2000" I should see "valid date..." Scenario: Separate with dashes (ok) When I fill in the date value with "01-13-2000" I should see "valid date..." etc Given the above, how should I write the 'create new patient' and 'create new incident' features? I don't want to copy and paste all the date related scenarios, but I do want to specify (and test) that the patient birth date and incident date fields conform to the general date rules. Here's how the 'create new patient' and 'create new incident' features would look with some copy and pasting: Feature: Create new Patient Scenario: Enter invalid birth date Given I fill in "birth date" with "13/01/2000" And I fill in "patient name" with "Sam Smith" When I press "Save" I should see "Invalid birth date '13/01/2000'" Scenario: Enter valid birth date, valid name Given I fill in "birth date" with "01/13/2000" And I fill in "patient name" with "Sam Smith" When I press "Save" I should see "Patient Created Successfully" Scenario: Enter valid birth date with dashses. --- Feature: Create new Incident Scenario: Enter invalid incident date Given I fill in "incident" with "13/01/2000" And I fill in "supervisor" with "Sam Smith" When I press "Save" I should see "Invalid incident date '13/01/2000'" Scenario: Enter valid incident date, valid supervisor Given I fill in "incident date" with "01/13/2000" And I fill in "supervisor" with "Sam Smith" When I press "Save" I should see "Incident Created Successfully" Scenario: Enter valid incident date with dashes - Am I making sense? I want to specify the date in the features, as there may be extra requirements like birth dates can not be in the future in addition to the generic date requirements. And I want to validate that the form checks for valid dates, displays the appropriate error message when invalid, and uses the common rules for parsing. But I don't want to copy and paste those scenarios in every feature. I think reusing steps as you mention is probably the solution but I'm stuck on how to word it and put it together in my case. Steve On Sun, Dec 14, 2008 at 8:41 AM, Matt Wynne wrote: > > On 13 Dec 2008, at 20:58, Steve Molitor wrote: > > What's the best way to handle a requirement that shows up as a >> sub-requirement requirement in other features? For example let's say users >> can enter dates in various forms throughout my application. There is one >> set of global rules specifying the formats in which dates may be entered, >> and how they are interpreted. I put that in one feature. In various other >> features, like 'Create new patient', one can enter dates, like the patient's >> birth date. I want to do something like 'and the date entry shall follow >> the normal rules' but I'm not sure how to do that in an example driven way, >> without copying and pasting from other features. >> >> Does my question make sense? Any suggestions? >> > > Do you know that you can call steps within steps? > http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/ > > Is that what you're looking for? > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > ___ > 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
Re: [rspec-users] Reuse of Cucumber Features
On 13 Dec 2008, at 20:58, Steve Molitor wrote: What's the best way to handle a requirement that shows up as a sub- requirement requirement in other features? For example let's say users can enter dates in various forms throughout my application. There is one set of global rules specifying the formats in which dates may be entered, and how they are interpreted. I put that in one feature. In various other features, like 'Create new patient', one can enter dates, like the patient's birth date. I want to do something like 'and the date entry shall follow the normal rules' but I'm not sure how to do that in an example driven way, without copying and pasting from other features. Does my question make sense? Any suggestions? Do you know that you can call steps within steps? http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/ Is that what you're looking for? Matt Wynne http://blog.mattwynne.net http://www.songkick.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing rails mailers
thanks a lot! This looks great. On Sun, Dec 14, 2008 at 4:21 AM, Mischa Fierer wrote: > I found this useful: > http://madhatted.com/2008/7/10/rspec-real-world-testing > > > On Thu, Dec 11, 2008 at 7:42 AM, Ivor Paul wrote: >> >> Hi Guys >> >> I am trying to spec some rails mailers. >> >> The only info I found was this post >> http://kpumuk.info/ruby-on-rails/testing-mailers-with-rspec/ >> by Dmytro Shteflyuk. >> >> I am hoping there is somewhat more on the topic - could someone point >> me towards a resource where I can find more? >> >> Regards >> Ivor >> ___ >> 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
