Tagged: capybara Toggle Comment Threads | Keyboard Shortcuts

  • kmitov 6:29 am on October 8, 2021 Permalink |
    Tags: capybara, , ,   

    [Rails] Warden.test_reset! does not always reset and the user is still logged in 

    We had this strange case of a spec that was randomly failing

      scenario "generate a subscribe link for not logged in users" js: true do 
    visit "/page_url"

    expect(page).to have_xpath "//a[text()='Subscribe']"
    click_link "Subscribe"
    ...
  end

    When a user is logged in we generate a button that subscribes them immediately. But when a user is not logged in we generate a link that will direct the users to the subscription page for them to learn more about the subscription.

    This works well, but the spec is randomly failing sometimes.

    We expect there to be a link, eg. “//a” but on the page there is actually a button, eg. “//button”

    What this means is that when the spec started there was a logged in user. The user was still not logged out from the previous spec.
    This explains why sometimes the spec fails and why not – because we are running all the specs with a random order

    $ RAILS_ENV=test rake spec SPEC='...' SPEC_OPTS='--order random'

    Warden.test_reset! is not always working

    There is a Warden.test_reset! that is supposed to reset the session, but it seems for js: true cases where we have a Selenium driver the user is not always reset before the next test starts.

    # spec/rails_helper.rb
RSpec.configure do |config|
  ...
  config.after(:each, type: :system) do
    Warden.test_reset!
  end
end

    Logout before each system spec that is js: true

    I decided to try to explicitly log out before each js: true spec that is ‘system’ so I improved the RSpec.configuration

    RSpec.configure do |config|
  config.before(:each, type: :system, js: true) do
    logout # NOTE Sometimes when we have a js spec the user is still logged in from the previous one
    # Here I am logging it out explicitly. For js it seems Warden.test_reset! is not enough
    #
    # When I run specs without this logout are
    # Finished in 3 minutes 53.7 seconds (files took 28.79 seconds to load)
    #   383 examples, 0 failures, 2 pending
    #
    # With the logout are
    #
    # Finished in 3 minutes 34.2 seconds (files took 21.15 seconds to load)
    #   383 examples, 0 failures, 2 pending
    #
    # Randomized with seed 26106
    # 
    # So we should not be losing on performance
  end
end

    Conclusion

    Warden.test_reset! does not always logout the user successfully before the next spec when specs are with Selenium driver – eg. “js: true”. I don’t know why, but that is the observed behavior.
    I’ve added a call to “logout” before each system spec that is js: true  to make sure the user is logged out.

     

  • kmitov 5:48 am on September 6, 2021 Permalink |
    Tags: capybara, , , ,   

    Refresh while waiting with RSpec+Capybara in a Rails project 

    This is some serious advanced stuff here. You should share it.

    A colleague, looking at the git logs

    I recently had to create a spec with Capybary+RSpec where I refresh the page and wait for a value to appear on this page. It this particular scenario there is no need for WebSockets or and JS. We just need to refresh the page.

    But how to we test it?

    # Expect that the new records page will show the correct value of the record
# We must do this in a loop as we are constantly refreshing the page.
# We need to stay here and refresh the page
# 
# Use the Tmeout.timeout to stop the execution after the default Capybara.default_max_wait_time
Timeout.timeout(Capybara.default_max_wait_time) do
  loop do
    # Visit the page. If you visit the same page a second time
    # it will refresh the page.
    visit "/records"
    # The smart thing here is the wait: 0 param
    # By default find_all will wait for Capybara.default_max_wait_time as it is waiting for all JS methods 
    # to complete. But there is no JS to complete and we want to check the page as is, without waiting 
    # for any JS, because there is no JS. 
    # 
    # We pase a "wait: 0" which will check and return
    break if find_all(:xpath, "//a[@href='/records/#{record.to_param}' and text()='Continue']", wait: 0).any?

    # If we could not find our record we sleep for 0.25 seconds and try again.
    sleep 0.25
  end
end

    I hope it is helpful.

    Want to keep it touch – find me on LinkedIn or Twitter.

     

  • kmitov 5:03 am on April 14, 2021 Permalink |
    Tags: capybara, ,   

    Rendering plain text from the server is not plain text in the browser 

    (Everyday Code – instead of keeping our knowledge in a README.md let’s share it with the internet)

    One thing that is good to know:

    If you render plain text from a web framework like Rails you will not have plain text in the browser. You will still have HTML in the browser.

    This bite us with one of the RSpec scenarios that we were running and I thought I should share with the team and the whole community.

    IRL

    The real life scenario is the following.

    In the Rails controller we do 

    class DigestMessagesController < ApplicationController
    def show
        render plain: "Text"
    end
end

    What we would expect to see in the browser is a simple “Text” text. If fact this is exactly what is returned by the server – you can see in the “Response” tab.

    you can see that the response from the server is just “Text”

    But if you now Inspect the content of the page in the browser you will see that there is HTML inside.

    
<html>
 <head></head>
 <body>
 <pre style="word-wrap: break-word; white-space: pre-wrap;">Text</pre>
 </body>
</html>

    This HTML was not returned by the framework. This HTML was added by the browser. This is not good because an RSpec system scenario with Capybara will pass with rack_test driver, but will fail with a Selenium driver. rack_test driver will not add this HTML while all the major browsers will add it.

    scenario 'for text' do
      visit "/digest_messages/#{digest_message.id}?preview=plain"
      expect(page.body.to_s).to include("Text")
      # This expect here will fail for Selenium and will pass for rack_test driver.
      expect(page.body.to_s).not_to include("html")
end

    I hope this is helpful and could save you a couple of minutes debugging.

     

  • kmitov 7:21 am on January 8, 2019 Permalink |
    Tags: capybara, chromedriver, , google-chrome, , , ,   

    Chromedriver not filling all the whole password field in automated RSpec, Capybara, Feature Tests 

    This is such a lovely story. You will like it.

    When using google chromedriver to run capybara tests sometimes, just sometimes, especially if the tests are run in parallel, when the test has to fill a text field like a password, it fills only part of it. Last time checked for chromedriver 2.45

    TL; DR;

    Solution – google does not care, or it seems it is too difficult for the chromedriver team to resolve so there simply is no solution.

    What is the test?

    We are using Rails, Rspec, Capybara, Google chromedriver. We are developing feature tests. Tests are run in parallel with 

    rake parallel:spec

    Here is the test in question. Simply fill a password on the form for upgrading a subscription, click on Confirm and expect to be redirected to a page that says – “You’ve upgraded your subscription”


    def submit_and_expect_success password
      # dialog opens to confirm with password
      fill_in "owner_password", with: password
      click_on "Confirm"

      expect_redirect_to "/subscriptions/#{subscription.to_param}"

      # If it redirects to this page, it means that the change was successful
      expect(page).to have_current_path "/subscriptions/#{subscription.to_param}"
end

    And the tests are failing with timeout at expect_redirect_to. No, expect_redirect_to is a custom method, because we are using ActionCable to wait for subscription upgrade to finish. Because of the payment service at the back this sometimes takes a while and we want to show a nice progress and we need a websocket. But that being said the method is nothing special. 

    module ExpectRedirect
  def expect_redirect_to url
    # If the path doesn't change before the timeout passes,
    # the test will fail, because there will be no redirect

    puts "expect url: #{url}"
    begin
      Timeout.timeout(Capybara.default_max_wait_time) do
        sleep(0.1) until url == URI(page.current_url).path
        page.current_url
      end
    rescue Timeout::Error=>e
      puts "Current url is still: #{page.current_url}"
      puts page.body
      raise e
    end
  end
end

    If we are redirected to the url withing Capybara.default_max_wait_time than everything is fine. If not, we are raising the Timeout::Error.

    Parallel execution

    For some reason the test in question fails only when we are doing a parallel execution. Or at least mostly when we are doing parallel execution of the tests. So we moved through some nice articles to revise our understanding of Timeout again and again.

    https://jvns.ca/blog/2015/11/27/why-rubys-timeout-is-dangerous-and-thread-dot-raise-is-terrifying/

    But nevertheless the tests were failing with Timeout::Error on waiting for a redirect and in the html we could see the error returned by the server:

    <div><p>Invalid password</p></div>

    How come the password is Invalid

    No this took a while to debug and it seems rather mysterious but this is what we got:

    User password in DB is: 10124ddeaf1a69e3748e308508d916b6

    The server receives from the html form: 10124ddeaf1a69e3748e30850

    User password in DB is: 74c2a3e926420e1a30363423f121fc1e

    The server receives from the html from: 74c2a3e926420e1a3

    and so on and so on.

    Sometimes the difference is 8 symbols. Sometimes it is 2. Sometimes it is 16.

    It seems to be a client side issue

    Like. JavaScript. If there is an error this strange it has to be in the JavaScript. Right. There in the javascript we see:

    let form_data = form.serializeObject();
this.perform('start_change', form_data);

    The form gets serialized. Probably it is not serialized correctly. Probably the values that we are sending are just not the values on the form. So I revised my knowledge on serializing objects in JavaScript with

    https://stackoverflow.com/questions/17488660/difference-between-serialize-and-serializeobject-jquery

    So far so good. But the serialization was not the problem. Here is what I did. I fixed all the passwords to be 32 symbols. 

    let form_data = form.serializeObject();
 if(form_data["owner_password"].lenght != 32) {
        form_data["owner_password"] = "this was:" + form_data["owner_password"] + " which is less than 32 symbols"
      }
this.perform('start_change', form_data);

    It it happened. The value of the password field was simply not 32 symbols long. It was not filled during the test.

    A little bit of search and we arrive at:

    https://github.com/teamcapybara/capybara/issues/1890

    and there in the bottom of the issue, there is the standard: “Not our problem resolution” with the link to:

    https://bugs.chromium.org/p/chromedriver/issues/detail?id=1771&q=sendkeys&sort=-id&colspec=ID%20Status%20Pri%20Owner%20Summary

    It seems that google chromedriver is not filling all the characters in the password field. It is doing it on random and is completely unpredictable.

    Issue still exists on:

    Issue still exist for

Chrome: Version 71.0.3578.98 (Official Build) (64-bit)
Chromedriver chromedriver --version
ChromeDriver 2.45.615279 (12b89733300bd268cff3b78fc76cb8f3a7cc44e5)
Linux kireto-laptop3 4.4.0-141-generic #167-Ubuntu x86_64 GNU/Linux
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial

    Today we would try Firefox driver.


     

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel