Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Thomas Walpole
    @twalpole
    (if login is redirecting to a different page)
    Gus P
    @staycreativedesign
    yes login redirects to a diff page
    whats a check that I need?
    Thomas Walpole
    @twalpole
    Check that the signup has finished before doing the login
    Assert on whatever text shows up when signup succeeds
    Gus P
    @staycreativedesign
    k
    Gus P
    @staycreativedesign
    expect(page).to have_content('Organizations')
    that pagges
    that passes
    expect(page).to have_content('You have logged in')
    passes
    Gus P
    @staycreativedesign
    User Load (0.3ms)  SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]
      Rendering organizations/index.haml within layouts/dashboard
      Organization Load (0.6ms)  SELECT "organizations".* FROM "organizations"
      Client Load (0.4ms)  SELECT "clients".* FROM "clients" WHERE "clients"."organization_id" = $1  [["organization_id", 1]]
      Rendered organizations/index.haml within layouts/dashboard (Duration: 5.2ms | Allocations: 4059)
    thats the test log
    Gus P
    @staycreativedesign
    as you should, you're using database-cleaner in transactional mode. Each spec example is performed in a transaction that gets rolled back, never committed to the database. The two processes/threads (spec runner and request handler) are each using their own database connection and therefore can't see database changes made in an uncommitted transaction in a different database connection.
    Gus P
    @staycreativedesign
    Ok why does my feature test pass but my system test fails when i change it from type
    Thomas Walpole
    @twalpole
    because feature tests and system tests have different settings
    Gus P
    @staycreativedesign
    ok
    ugh
    Phuc Trinh
    @trinhcanhphuc

    I was testing with rails system test with internet explorer.
    I configed applications_system_test_case.rb to

    class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
      driven_by :selenium, using: :internet_explorer
    end

    In my test file. I wrote:

    assert_empty page.driver.browser.manage.logs.get(:browser)

    When I run rails test:system. Rails console return this error:

    NoMethodError: undefined method `log' for #<Selenium::WebDriver::Remote::W3C::Bridge:0x000000000f03c5f0>

    Can you help me to resolve this bug. Thanks

    Uwe Kubosch
    @donv
    Hi all! I have set up a capybara test project for a Java SpringBoot application, and it works well. I start the server with a server block:
      Capybara.server = ->(_app, _port, _ip) {
        env = { 'SPRING_PROFILES_ACTIVE' => 'development,browser_test' }
        Open3.popen2(env, './gradlew', 'bootRun',
            chdir: ENV['DLC_SERVER_PATH'] || '../dlc_server') do |_i, stdout, thread|
          start_time = Time.zone.now
          stdout.each_line do |line|
            puts line
            break if /Started LightControlBootApplication/.match?(line)
          end
          puts "Server started OK #{(Time.zone.now - start_time).to_i}s"
          server_process = thread
          raise 'Server failed' unless thread.value.success?
    
          puts 'Server stopped OK'
        end
      }
    I need to run one test suite with a different set of SPRING_PROFILES_ACTIVE. Any idea to best set this up?
    Gus P
    @staycreativedesign
    how would I find this using capybara
    <link rel="image_src" href="https://i.ytimg.com/vi/gWfOd-6pTNI/hqdefault.jpg">
    Thomas Walpole
    @twalpole
    You can search by href
    Gus P
    @staycreativedesign
    hmmm
    ok
    I guess how would I find the value of href for image_src
    i want to get the value of href
    Thomas Walpole
    @twalpole
    But it doesn’t actually show on the page right? So you’d need to specify visible: false
    Gus P
    @staycreativedesign
    find("link[rel='image_src']", visible: false)
    ha!
    Thomas Walpole
    @twalpole
    If it’s the only image_arc link on the page you could do something like find(‘link[rel=“image_src”]’)[:href]
    Gus P
    @staycreativedesign
    yep
    thanks man :)
    find("link[rel='image_src']", visible: false)['href'] is what I ended up doing !
    Thomas Walpole
    @twalpole
    Yeah - slow to type code on phone
    Gus P
    @staycreativedesign
    woot!
    Gus P
    @staycreativedesign
    Boris Petrov
    @boris-petrov

    Hi, I don't understand how Capybara works with textarea. I have this code:

        visit 'file:/home/boris/x.html'
        expect(page).to have_text('asd')
        find('textarea').set('foobar')
        expect(page).to have_text('foobar')

    And this x.html:

    <textarea>asd</textarea>

    This fails on the last line with: expected to find text "foobar" in "asd". But I literally change the textarea's text to foobar on the previous line. Why doesn't that work?

    Thomas Walpole
    @twalpole
    @boris-petrov Are you sure 'asd' isn't located elsewhere on the page? text shouldn't match field values - it matches "static" text in the page (text in div,span, etc elements). To match on field contents/value you'd do expect(page).to_have_field(type: 'textarea', with: 'foobar')
    Boris Petrov
    @boris-petrov
    @twalpole - well, there is no other asd as what I pasted is literally the whole x.html file. But asd is in there so that's why have_text finds it I guess. Thank you for telling me about to_have_field... I've been writing Capybara for many years now and I didn't know about it. :D I'll try it out.
    Boris Petrov
    @boris-petrov
    And what do I replace find('textarea', exact_text: 'asd').set('foobar') with?
    Thomas Walpole
    @twalpole
    @boris-petrov Well first you should change x.html to actually be valid html if that's all that's in. it - but as for setting it you can do what you're doing or you could do something like fill_in(currently_with: 'asd', with: 'foobar')
    and sorry - it should be expect(page).to have_field(...) not sure how the extra _ got in there
    have_field(...) is the same as have_selector(:field, ...)
    Boris Petrov
    @boris-petrov

    @twalpole thanks for the help! find('textarea', exact_text: 'asd').set('foobar') won't work always. For example:

        visit 'file:/home/boris/x.html'
        expect(page).to have_text('asd')
        find('textarea').set('foobar')
        expect(page).to have_field(type: 'textarea', with: 'foobar')
        find('textarea', exact_text: 'foobar').set('barbaz')

    The last line here doesn't work. Changing it to fill_in(currently_with: 'foobar', with: 'barbaz') does work.
    It's a bit unfortunate that there are two APIs that do similar things but one must use one or the other depending on how the underlying HTML works. expect(page).to have_text('foobar') is very similar to expect(page).to have_field(type: 'textarea', with: 'foobar') but the former doesn't work in some cases. Same with find('textarea', exact_text: 'foobar').set('barbaz') and fill_in(currently_with: 'foobar', with: 'barbaz'). Is that only for textarea by the way? That is, can you think of other cases where the same will happen - have_text and find(..., exact_text: ...) won't work but their counterparts will?

    Thomas Walpole
    @twalpole
    @boris-petrov have_text should not be finding fillable field contents - that's either undefined behavior or a bug and you just shouldn't be using it for that. set is the lower level method that fill_in uses to do what it does , while fill_in does a little extra work but in the end calls set - You should be using fill_in. The fact that you're seeing set not working in your use case may be a bug - if you create a reproducible example and file an issue on the capybara project I'll take a look.
    Thomas Walpole
    @twalpole
    @boris-petrov Re-reading what you're doing the reason the last line doesn't work - is because changing the fields value doesn't change it's text (text != value). You can see this in a real browser by changing the textareas value and then checking its innerHTML. It will still be the original content of the element. The racktest driver mimics this behavior. So if you'd done find('textarea').set('barbaz') it would have worked or if you'd done find(:field, with: 'foobar').set('barbaz')` it would work - but instead you're matching on text, which as I stated above you should not be doing for the contents of fillable fields (textarea, input)
    Boris Petrov
    @boris-petrov
    @twalpole - yes, I understand that changing a textarea's value doesn't change the text in the innerHTML. And (now) I understand that have_text works on the HTML and not on the "visible" text to the user. That's what I was saying - that I would expect have_text to work on anything the user would see - in the HTML or in element values. Of course, I haven't really thought this through so maybe that doesn't make sense.
    In any way, I understand what's going on now, why things work or don't work, and I've fixed my tests. :) So all is good. Thank you for the support!