2016-02-07 2 views
1

Примеров художественных для сноски я использовал этот код:Какое правильное использование метода capybara внутри?

feature 'in footer' do 
    scenario "has a Copyright text" do 
     within('footer') { 
     expect(page).to have_content "Copyright" 
     } 
    end 

    scenario "has navigation bar" do 
     within('footer') { 
     expect(page).to have_selector 'nav ul li' 
     } 
    end 

    scenario "has a link for 'About'" do 
     within('footer') { 
     expect(page).to have_link 'About', href: '#' 
     } 
    end 
end 

Если вы посмотрите внимательно, я повторил «в» в каждом сценарии и эти конфликтах с сухостью кода.

Я не хочу включать все ожидания в один сценарий, потому что мне нужно объяснение для каждого из них.

Каков наилучший способ использования внутри метода в этой ситуации?

ответ

1

Там нет никакого способа, чтобы высушить использование #within и до сих пор есть несколько сценариев. Кто-то может попытаться использовать фильтр вокруг, но из-за упорядочения фильтров вокруг и до/после он не работает. Вы можете получить то, что вы ищете, не используя #within, находя колонтитула в блоке перед тем, а затем ожидать от что

before do 
    visit('my page') 
    @footer = find('footer') 
end 

scenario 'blah blah' do 
    expect(@footer).to have_content('...') 
end 

скажу, что написание функциональных тестов только для проверки строки текста на страница не является большой практикой. В функциональных тестах много накладных расходов, и проверка строки текста, которая не зависит от каких-либо действий пользователя, действительно больше подходит для теста просмотра, а не для функции (вы все равно можете использовать Capybaras matchers in view). Функциональные тесты должны быть для тестирования более крупных поведений в системе.

+0

Спасибо, Том. не могли бы вы объяснить некоторую разницу между тестами просмотра и функциональными тестами? Я думал, что они такие же: | – Ahmad

+0

, кстати, я задал отдельный вопрос здесь: http://stackoverflow.com/questions/35258592/is-there-any-difference-between-feature-test-and-view-test – Ahmad

+0

+1 для "написания функциональных тестов только для проверки строки текста на странице не является большой практикой "... особенно когда" проверка строки текста, которая не зависит от каких-либо действий пользователя. –

1

Вы можете создать один метод, чтобы исключить повторение метода внутри.

Например:

feature 'footer' do 
    scenario 'footer has copyright text, navigation bar and link for about' do 
    within('footer') { 
     expect(page).to have_content "Copyright" 
     expect(page).to have_selector 'nav ul li' 
     expect(page).to have_link 'About', href: '#' 
    } 
    end 
end 
+0

спасибо. но я хочу отдельное объяснение для каждого из них – Ahmad

+0

ли методы capybara не дают достаточного объяснения? 'to have_content" Авторское право "' относительно описательно. Я не уверен, что «текст авторского права» добавляет большую часть объяснений. –

+0

Когда вы запускаете примеры с -f d-переключателями команды rspec, метод capybara не появляется, не так ли? Я хочу это объяснение, которое печатает на оболочке. – Ahmad

Смежные вопросы