interacting via capybara/selenium

[jrochkind]

I do automated testing with capybara (Rails app). I think similar issues would occur using other uses of selenium, but can't say.

Does anyone have a good solution to automating interaction with a tom-select-covered input?

Googling around, there are various solutions offered for selectize... of various quality, some of them seem wrong, or outdated and no longer work with contemporary selenium, which looks like it's gotten pickier about forbiding interaction with non-visible elements.

Some of them might not exactly apply to tom-select anymore even if they might work for selectize. Some of them seem to use the selectize JQuery-style API to use Javascript to set a value for the selectize input, like selectNode.selectize.setValue... that I don't think there's an equivalent way for Javascript to get acess to the tom-select object from a select node?

With all the reasons a given solution found on google might not work... I am going through what I can find to try to figure out what might work, but was wondering if anyone had already figured it out and had a good solution.

[jrochkind]

OK, continuing to answer my own questions....

If you do want to do it via Javascript, I discovered that the the tom-select object is available on the property tomselect of the original input node. (not sure if that's documented anywhere? Not totally sure how I discovered it! Might be a good thing to document on https://tom-select.js.org/docs/api/).

So in straight Javascript, you can do something like:

document.querySelector("#someInput").tomselect.setValue("anOptionValue")

So, translated to ruby capybara and rspec, one approach:

# ./spec/support/rspec_helper/tom_select.rb
module RspecHelper
  module TomSelect

    # A helper for Capyabara tests that need to set values from a tom-select.js input.
    #
    # This is a really hacky approach using execute_javascript, but it works. Not sure if there's
    # a better way, we could try actually interacting with the on-screen tom-select-provided UI,
    # but we're taking the easy way out for now.
    #
    # @param option_id can be the `id` value of an option in the select, OR for select multiple inputs,
    #   can be an array of such IDs.
    #
    # @example tom_select("#select_id", option_id: "2")
    # @example tom_select("#select_id", option_id: ["2", "10"]) # `multiple` input.
    def tom_select(select_selector, option_id:)
      js_str = %Q(document.querySelector("#{select_selector}").tomselect.setValue(#{option_id.inspect}))
      execute_script(js_str)
    end
  end
end

# spec_helper.rb

require './spec/test_support/rspec_helper/tom_select'
config.include RspecHelper::TomSelect, type: :system

So... this works! Using Capybara/selinium execute_script.

The other way to do it, that would be more "legit" Capybara/selinium, would be to try to write your script to actually interact with the on-screen UI provided by tom-select.

If anyone happens to see this and has done that, please share what worked. Or curious if anyone has an opinion the best way to do this.

[tomdracz]

Late to the party but hopefully someone finds this useful!

@jrochkind Something I've wipped up recently for multi selects:

  def fill_in_tom_select_field(container, value)
    within(container) do
      find('.ts-control input').send_keys(value)
    end

    all('.ts-dropdown .ts-dropdown-content .option', text: /#{Regexp.quote(value)}/i)[0].click
  end

Container is my case is that parent container of the field where tom-select is attached, value is the text I'm passing
If you sending exactly what you need to be set, then probably the method that dispatches click could be streamlined by fair bit. Could potentially just look for .option.active and dispatch click to that. Had to avoid doing this as in my test setup I had values like "Foobar 2 Office 1" and "Foobar 1 Office 2" - sending "office 2" as a value, highlights the "Foobar 2 Office 1" option first which is non-ideal, I guess it's how sorting functions does its thing.

[lucashour]

Thanks for the solution, @tomdracz! I used your code and built another helper which is similar to the existing Capybara's select, so instead of sending a container, you could send the label. In my case, since I'm grouping select and label inside a .form-group element, this is the result:

def select_autocompleted(value, from:)
  container = find(:label, text: from).ancestor('.form-group')

  within(container) do
    find('.ts-control input').send_keys(value)
  end

  all('.ts-dropdown .ts-dropdown-content .option', text: /#{Regexp.quote(value)}/i)[0].click
end

[tomdracz]

Thanks for the solution, @tomdracz! I used your code and built another helper which is similar to the existing Capybara's select, so instead of sending a container, you could send the label. In my case, since I'm grouping select and label inside a .form-group element, this is the result:

def select_autocompleted(value, from:)

  container = find(:label, text: from).ancestor('.form-group')



  within(container) do

    find('.ts-control input').send_keys(value)

  end



  all('.ts-dropdown .ts-dropdown-content .option', text: /#{Regexp.quote(value)}/i)[0].click

end

Great addition!

[TheRealNeil]

Thanks both, I made a small adjustment to deal with adding new options that don't exist e.g. tags

def tom_select(value, from:)
  container = find(:label, text: from).ancestor('.md-form')
  within(container) do
    find('.ts-control input').send_keys(value, :enter)
  end
end

[artur79]

why you use guys all(....)[0] instead first(...) ? Any reason or just preference ?

[dacook]

Thanks for sharing your learnings!

Because it requires knowledge of some of the inner workings of tom-select, it would be better in the long run to create helpers and custom matchers, similar to what select2 has: https://github.com/Hirurg103/capybara_select2 (for example).

As far as I can tell, still nothing like this exists yet. Hopefully someone (maybe myself) will get to do it one day...

[mikz]

For anyone landing here because this stopped working, check out f5218a7 and set the refresh timeout to 0.

[mikz]

as an option to tom select refreshThrottle: 0

https://github.com/search?q=repo%3Aorchidjs%2Ftom-select%20refreshThrottle&type=code

[artur79]

Thanks, what is exactly the impact of having it left with default value of 300ms, as I remember. The list of options do not load immediatelly ? I'v got the issue with random fails in some of my tom select custom specs (on github actions especially) and I'm trying to spot for the reason.

[mikz]

Yep. The test suite will write faster than that and Tom select will debounce the events,so some will not trigger and for example not show the options.

[artur79]

Does it still make sense if I don't load options from the server? Just standard way options from select.

[mikz]

Yes.

[mikz]

There is also a simpler way to fill it with recent capybara: fill_in(from, with: value, visible: false).send_keys(:return)

[jrochkind]

thank you!

[artur79]

visible: :all or visible: :hidden will satisfy rubocop ;)

[dfl]

This is what worked for me:

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
...
  setup do
    Capybara.app_host = "http://localhost" # so auth cookies are passed with fetch request vs. 127.0.0.1
  end

  def tom_select(value, from:)
    fill_in(from, with: value, visible: false).send_keys(:return)
    first('.ts-dropdown .ts-dropdown-content .option', text: /#{Regexp.quote(value)}/i).click
  end
...
end

Also, I set refreshThrottle and loadThrottle to zero in test env

[dfl]

to make it work with multi-selects, I had to change it to this:

 def tom_select(value, from:)
    fill_in(from, with: value, visible: false).send_keys(:return)
    select = find(:label, text: from).sibling('select')
    if select[:'data-tom-select-max-items-value'] == "1"
      first('.ts-dropdown .ts-dropdown-content .option', text: /#{Regexp.quote(value)}/i).click
    else
      find(:label, text: from).sibling('.ts-wrapper').find("input").click
    end
  end