2016-07-27 1 views
3

В наших автоматизированных тестах, типичная строка в коде может выглядеть примерно так:Как настроить искатели Capybara на сайте с помощью css-модулей?

find('.edit-icon').click

Мы находимся на пути к использованию CSS-модулей в нашем проекте, и я был предупрежден, что имена классов может резко измениться. Довольно смешной пример это сайт, который использует смайлики в своих именах классов (когда вы проверяете страницу):

css modules by Glenn Maddern

Как я мог бы лучше подготовиться к изменению этого резкому? Я думаю, что многие из наших спецификаций ломаются, но я немного беспокоюсь о том, что не могу вообще писать тесты с этой новой технологией в нашем проекте.

+1

Один из способов заключается в использовании пользовательской водосвинки селекторов - https: // GitHub .com/jnicklas/capybara/blob/master/lib/capybara/selector.rb - для абстрактных вещей, чтобы вы могли делать что-то вроде 'find (: edit_button) .click'. Полный ответ, хотя это «все зависит» - почему вы использовали класс css в первую очередь? –

+0

В приведенном выше примере, который распространен во всем моем проекте, я заканчиваю кнопками и другими элементами, которые не могут быть найдены ни с каким идентифицирующим текстом или другими атрибутами. Я также предпочитаю использовать селектор классов, чтобы избежать каких-либо двусмысленных/ложных срабатываний при написании ожиданий (например, если ожидается, что какой-то текст перейдет из одной области в другую). Я надеюсь, что по мере продвижения нашего проекта я могу привести несколько более конкретных примеров. Классы обычно не используются в автоматизированных спецификациях? Спасибо за помощь, Том. – Phil

+0

Да, классы используются довольно много - хотя я стараюсь использовать их в качестве последнего средства. Элементы, в которых нет текста, других атрибутов и т. Д., Являются основным вариантом использования. Как я уже говорил, пользовательские селектора могут помочь здесь - Capybara.add_selector (: edit_button) {css do | локатор | '.edit-icon' end}, который затем изолирует css до одного места. Когда имена классов изменяются, вы можете изменить этот селектор и, возможно, сделать что-то вроде «[class * =« \ _ edit \ _ »]», когда вы переходите к модулям css, в зависимости от того, как имена классов заканчиваются составлением –

ответ

2

С помощью пользовательских селекторов capybara вы можете абстрагироваться от фактического выполняемого запроса css и переместить его в одно место. В ваших комментариях вы упомянули о необходимости изменить атрибут класса, который начинается с переданного значения.

Capybara.add_selector(:class_starts_with) do 
    css { |locator| "[class^=\"#{locator}\"]" 
end 

бы сделать это, и тогда можно назвать

find(:class_starts_with, 'something') 

или если вы установите Capybara.default_selector =: class_starts_with было бы просто

find('something') 

Вместо того, чтобы изменить default_selector другой вариант было бы просто определить вспомогательный метод, например find_by_class_start, или что-то, что просто вызывает find с: class_starts_with прошло (как работает Capybara #find_field и т. д.).

Также обратите внимание на пользовательском селектор выше будет только действительно работать, если только одно имя класса было установлено, если несколько, как ожидается, вы можете изменить селектор "[class^=\"#{locator}\"], [class*=\" #{locator}\"]"

+0

Привет, Том, есть ли способ добавить пользовательский матчи для 'have_css', как мы это делали для' find () '? Я тоже не могу найти документацию. – Phil

+1

@Phil 'has_css (...)' в основном просто 'has_selector (: css, ...)' и 'has_selector (...)' по умолчанию для Capybara.default_selector, если другой селектор не прошел. Поэтому вы можете сделать 'has_selector (: class_starts_with, ...)' –

+0

А, я этого не знал! Благодарим вас за помощь через всю эту тему. Я очень, очень ценю это. – Phil

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