#145 ✓resolved
Chris Flipse

handle multiselects

Reported by Chris Flipse | January 24th, 2009 @ 06:26 PM

(I might just be blind and not seeing this ...)

I have a couple of forms with multiselect fields, and I would like to not have to drop down to constructing the post myself in order to test those forms with multiple values.


<label for=toppings>Toppings</label>
<select multiple=multiple name=toppings>
  <option>Pepperoni</option>
  <option>Sausage</option>
  <option>Ham</option>
  <option>Pineapple</option>
  ....
</select>

I'm kinda fine with putting everything into an array for the multiselect, although that's probably not going to play terribly well with Cucumber, long term


  select ["Ham", "Pineapple"], :from => 'toppings'  

maybe a different method is called for (it's different enough in the browser ...)


  multiselect "Ham", :from => "topping"
  multiselect "Pineapple", :from => "toppings"

I know multiselects aren't exactly the best UI elements, but they're in the forms I'm trying to get under test, and I'd like to be able to test them without resorting #post and #put ...

Comments and changes to this ticket

  • Hans de Graaff

    Hans de Graaff April 10th, 2009 @ 10:04 AM

    • Tag set to featurerequest

    Currently multiselects are also broken in that webrat picks the first item as selected even if nothing is selected, while actual browsers don't select anything in that case.

  • Mathias Meyer

    Mathias Meyer April 23rd, 2009 @ 02:46 PM

    I needed this too, so I implemented a new method "select_multiple". I tried extending the existing code for handling selects, but the handling was just too different. So I added a method to specify them like so:

    
    select_multiple ["Ham", "Pineapple"], :from => "toppings"
    

    The patches are in this branch

    I haven't added support for regexps yet, simply because I wasn't sure how to handle it. A single regexp could mean it should match all the options that match the regexp, and an array could mean it should only match one option, but it could also mean match all options with that regexp. I'd be happy to implement it, but I'm not yet in the clear about the API.

    Let me know what you think.

  • Mathias Meyer

    Mathias Meyer April 23rd, 2009 @ 04:51 PM

    • Tag changed from featurerequest to featurerequest, patch
  • gaffo

    gaffo May 7th, 2009 @ 07:06 PM

    • State changed from “new” to “awaiting-merge”

    Needs to be verified but it's all just test changes. Might need to be broken up.

  • Mathias Meyer

    Mathias Meyer June 4th, 2009 @ 04:19 AM

    • Assigned user set to “gaffo”

    Has this a chance of getting merged into the webrat master? It's not just a couple of test changes, I did those after real-life testing the patch, so it's a bigger change in all. Should I rebase it against the current master to make sure it'll be a clean merge?

  • gaffo

    gaffo June 4th, 2009 @ 01:55 PM

    • State changed from “awaiting-merge” to “open”

    Mathias,
    There are few things that I can think of:

    1) If the API is good / consistent, and which one to use.
    2) Making sure that it works in webrat mode
    3) Making sure that you can do the same thing in selenium.
    4) Keeping the patch applyable

    #1 needs some discussion and thought. I'd try and get brynary involved in that one either by asking him on the irc channel or mailing the list. #2 you seem to have #3 is pretty easy to do by adding some tests to spec/integration/rails and then running both modes, and it's a very nice to have. #4 is just nice because it allows anyone to more easily try it out.

    Thanks for the work. The big issue is how the API should look because we don't want to deprecate it later (it's a pain).

  • Daniel Morrison

    Daniel Morrison July 15th, 2009 @ 01:56 PM

    I updated the multiple select handling that Mathias wrote and its available in Collective Idea's multiselect branch.

    I fixed bugs with default_value and added tests.

  • Kieran P

    Kieran P August 30th, 2009 @ 12:06 AM

    This is still an issue, and has stopped me from testing parts of my application which have been discovered to have recently formed bugs. Fixing this ASAP would be greatly appreciated. I'll see if I can find time to test the patches above and provide feedback.

  • Kieran P

    Kieran P August 31st, 2009 @ 02:47 AM

    I tested the above patches/commit links. None really worked well, or were clean. So I wrote my own (based of the code).

    http://github.com/KieranP/webrat/commit/a8d0cebde3880b98444c2c53cf7...

    Multiple select fields work nicely with that commit. It's fully tested (specs and manually) and working, there is documentation, specs/tests, it applies cleanly to webrat master. And the api is clean and consistant with check/uncheck.

    I'll be very surprised if it isn't included in the next release.

    It also fixes a few bugs outside the scope of this ticket ticket (because I felt like helping out) ^_^

    Namely, ampersands in option values. The fix for this also fixes a similar click_button pending test of the same issue. All specs are passing with these changes. Can we finally get this one resolved please? 7 months for a 2 hour fix is too long IMHO.

  • Bryan Helmkamp

    Bryan Helmkamp September 7th, 2009 @ 01:09 PM

    (from [a8d0cebde3880b98444c2c53cf7952d31400826b]) Various improvements, refinements, and bugfixes for select field usage.

    Multiple select boxes are now handled a lot better.
    * You can now select more than one field (where as previously, the last one select would override previous selections) * You can now unselect a value. It works like select, takes the same params, but removes the selection value

    Issues regarding ampersands in values have been resolved.
    * Values are now unescaped when the to_param method is run on elements, to make assertions less complicated * Locating an option with ampersand values now works as expected (it will check for both escaped and unescaped occurrences)

    Bunch of new specs and 3 broken pending ones have now been fixed. [#145 status:resolved]
    http://github.com/brynary/webrat/commit/a8d0cebde3880b98444c2c53cf7...

  • Bryan Helmkamp

    Bryan Helmkamp September 7th, 2009 @ 01:15 PM

    • State changed from “open” to “resolved”

    Hey Kieran,

    Thanks for the patch. It's merged into master now.

    I made one minor behavioral change... Instead of matching against either the HTML or text version of select options, I've limited it to checking just the text version.

    I'd like for all of Webrat to work this way, because I think it's the right level of abstraction, and consistent with how the behavior is described from a black box perspective. Currently, it's inconsistent across Webrat, and I'll keep working to get that straightened up.

    Cheers,

    -Bryan

  • Kieran P

    Kieran P September 7th, 2009 @ 05:44 PM

    Hey Bryan,

    Thanks for merging it in. Will be nice to be able to test these now.

    Would you say the next release is a fair bit away?

    Regards
    Kieran

  • Bryan Helmkamp

    Bryan Helmkamp September 7th, 2009 @ 06:03 PM

    Yes, the next major (0.6) release won't be for a while.

    There are a lot of things either in master or that I'm considering for master that are significant or non-backward compatible changes, and I want to make sure the upgrade is as smooth as possible.

    Cheers,

    -Bryan

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Ruby Acceptance Testing for Web applications.

Shared Ticket Bins

Referenced by

Pages