Y a-t-il un avantage à définir des boutons radio dans un modèle Page Object (par exemple, SitePrism) plutôt que d'utiliser directement Capybara?

Question

J'utilisais un framework concombre/ruby ​​/ capybara/siteprism et implémentais les pages de test actuellement. J'ai atteint un point où il y a beaucoup de boutons radio (plus de 20) par page sur plusieurs pages, et je me demandais s'il y avait vraiment un avantage à essayer de les cartographier comme des éléments statiques dans mon modèle d'objet page. Par exemple, il semble beaucoup plus pratique d'utiliser simplement le texte du bouton radio dans la définition d'étape et d'appeler directement la méthode capybara 'choose', quelque chose comme le suivant, de sorte que je n'ai pas besoin de faire quoi que ce soit d'autre pour les plus de 20 boutons radio, il doit tous travailler en changeant le paramètre que nous transmettons dans la fonction:

cucumber feature: 
    When I select that "I am over 18" 

capybara step: 
    When /^I select that "(.*)"$/ |option| 
     choose(option) 

Alors qu'avec un modèle d'objet page comme siteprism, je suppose que la mise en œuvre aurait besoin définir et maintenir tous ces éléments indépendamment dans un format semblable à:

element :over_18_button, :radio_button, "I am over 18" 
element :over_12_button, :radio_button, "I am over 12" 
etc x50times 

Et pour l'utiliser, il faut créer la page, appeler l'élément, ce qui ne me semble pas aussi simple?

siteprism step: 
    When /^I select that "(.*)"$/ |option| 
    case option 
     when 'I am over 18' 
      over_18_button.click 
     when 'I am over 12' 
      over_12_button.click 

Je suppose que l'on pourrait créer des « éléments » ou une « section » avec un tableau à tous les boutons, mais, nous allons devoir mettre la logique supplémentaire pour les analyser et cliquez sur l'une de toute façon pertinente quelque part dans le code, alors que tout serait fait proprement et sans besoin de code supplémentaire ou de maintenance avec la méthode 'choose' de capybara.

Ai-je raison de supposer que dans cet exemple utiliser Capybara est une meilleure option? ou s'il serait préférable de définir «TOUS» les éléments Web dans le modèle d'objet de page, quel serait l'avantage de cela? et le code d'objet de page pourrait-il être fait d'une manière différente pour tirer profit de n'importe quel avantage possible?

PS: ajouter la balise de page objet ', « watir » aussi bien que je suppose que la structure conceptuelle des essais serait similaire à quelqu'un, peut-être en utilisant ce cadre peut aider aussi bien ...

Answer 1

Cette instruction complexe n'est pas nécessaire.

When /^I select that I am over "(\d\d)"$/ |age| 
    @page_object.select_age(age) 

Je ne connais pas le site_prism. Mon watir_drops bijou vous permettrait de définir tout avec le même motif comme celui-ci:

element(:age_button) { |age| browser.radio_button(text: "I am over #{age}") 

avec cette méthode dans l'objet de la page:

def select_age(age) 
    age_button(age).set 
end 

On pourrait aussi entrer dans une longue discussion tout sur l'utilisation déclarative à la place des étapes impératives. En outre, meilleure pratique L'utilisation de l'objet Page évite d'appeler directement des éléments définis. Les méthodes d'appel qui accomplissent la logique métier et ces méthodes effectuent toutes les implémentations, y compris les définitions d'éléments et les actions sur celles-ci.