Як стверджувати кількість елементів за допомогою Capybara з належним повідомленням про помилку?


86

Я знаю, що в Capybara ви можете зробити щось подібне:

page.should have_css("ol li", :count => 2)

Однак, якщо припустити, що сторінка має, наприклад, лише один відповідний елемент, помилка не дуже описова:

  1) initial page load shows greetings
 Failure/Error: page.should have_css("ol li", :count => 2)
 expected css "ol li" to return something

Замість цього досить незрозумілого повідомлення про помилку, чи є спосіб написати твердження таким чином, що висновок про помилку буде виглядати приблизно так: "При збігу з" ol li ", очікується: 2, знайдено: 1". Очевидно, я міг би зробити власну логіку для такої поведінки - я запитую, чи є спосіб зробити це "нестандартно"?

Для цього я використовую драйвер Selenium та RSpec.


Щоб люди лише знали, "page.should have_css (" ol li ",: count => 2)" було реалізовано в capybara. Я вважаю, що він дуже корисний для областей: у межах ("ol.users-list") do page.should have_css ('li',: count => 3) end
rafaelkin

@rafaelkin, лише для уточнення: чи повідомляє тепер капібара, наприклад, про невідповідність підрахунку елементів більш детально? Я не стежив за capybara вже деякий час, але проблема тоді, коли я поставив запитання, стосувалася формату повідомлення про помилку, не те, що page.should have_css("ol li", :count => 2)вже не було реалізовано.
merryprankster

люди, я відчуваю, що прийнята на даний момент відповідь (= моя власна) вже не найкраща, але у мене немає часу (більше не працювати з Рубі), щоб оцінити, яке із запропонованих рішень є найкращим. Я зміню прийняту відповідь на відповідь Річарда лише тому, що вона включає результати твердження, що стосуються вихідної проблеми.
merryprankster

Відповіді:



22

Ну, оскільки, здається, немає нестандартної підтримки, я написав цей спеціальний збіг:

RSpec::Matchers.define :match_exactly do |expected_match_count, selector|
    match do |context|
        matching = context.all(selector)
        @matched = matching.size
        @matched == expected_match_count
    end

    failure_message_for_should do
        "expected '#{selector}' to match exactly #{expected_match_count} elements, but matched #{@matched}"
    end

    failure_message_for_should_not do
        "expected '#{selector}' to NOT match exactly #{expected_match_count} elements, but it did"
    end
end

Тепер ви можете робити такі речі:

describe "initial page load", :type => :request do
    it "has 12 inputs" do
        visit "/"
        page.should match_exactly(12, "input")
    end
end

і отримати результат, як:

  1) initial page load has 12 inputs
     Failure/Error: page.should match_exactly(12, "input")
       expected 'input' to match exactly 12 elements, but matched 13

Поки що це робить трюк, я розгляну створення цієї частини Капібари.


Схоже, виправити це в Capybara не просто: github.com/jnicklas/capybara/issues/331
merryprankster

14

Я думаю, що наступне простіше, дає досить чіткий результат і позбавляє потреби в спеціальному збігу.

page.all("ol li").count.should eql(2)

Потім друкується з помилкою:

      expected: 2
       got: 3

  (compared using eql?)
  (RSpec::Expectations::ExpectationNotMetError)

9
Це не чекає, поки очікування збудуться, наприклад, коли ще є очікувані запити ajax.
Clemens Helm

9

Редагувати: Як зазначив @ThomasWalpole, використання allвідключає очікування / повторну спробу Capybara, тому відповідь вище від @pandaPower набагато краща.

Як щодо цього?

  within('ol') do
    expect( all('.opportunity_title_wrap').count ).to eq(2)
  end

2
Це повністю усуває очікування / повторну спробу Капібари, і це ніколи не повинно бути рекомендованим рішенням.
Томас Уолпол

@ThomasWalpole Я не впевнений, про що ти говориш. Як пошук елемента в іншому елементі будь-яким чином стосується очікування / повторної спроби в Capybara?
Постійний Мерінг

2
@ConstantMeiring Це не те within, воно вимагає .countрезультатів, allщо відключає очікування / повторну спробу. Викликаючи countрезультати all(для яких порожній "масив" є дійсним поверненням), ви перетворюєте на ціле число і порівнюєте його. Якщо це порівняння не вдається, очікування не вдається. Якщо замість цього ви передасте параметр підрахунку одному із збігів Capybara, capybara буде чекати / повторити спробу пошуку вказаного селектора, поки параметр підрахунку не збігається (або Capybara.default_max_wait_time закінчується).
Thomas Walpole

4

На сьогоднішній день (02.09.2013) найкраща практика, рекомендована Capybara, така ( джерело ):

page.assert_selector('p#foo', :count => 4)


-4

Відповідь @pandaPower дуже хороша, але синтаксис для мене був дещо іншим:

expect(page).to have_selector('.views-row', :count => 30)

5
Використання хеш-ракет не кваліфікується як "різний синтаксис".
premjg

2
Я не рубіновий розробник і не розумів, що два синтаксиси еквівалентні. TBH Я не впевнений, що це виправдовує голосування проти. Це дійсна альтернатива. Для тих, хто не з Ruby фону, це може здатися не очевидним. Це було не для мене.
Нік
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.