Vérifier l'attribut spécifique d'une balise html existe dans Capybara avec interrogation

Question

J'ai ce simple HTML. Les attributs des boutons (tels que "AAAAA") transitent par événement externe. La mise à jour en temps réel est exécutée par pooling AJAX.

<div class="parent"> 
<div class="group"><button title="AAAAA"/></div> 
<div class="group"><button title="BBBBB"/></div> 
<div class="group"><button title="CCCCC"/></div> 
</div> 
<div class="parent"> 
... 
</div> 

Supposons que "AAAAA" passera à "DDDDD" après l'événement XXX. Le script de test serait comme ...

scenario 'test' do 
    # Before change 
    page.within(first('.parent')) do 
     page.within(all('.group')[0]) do 
      expect(page.find('button')[:title]).to include('AAAAA') 
     end 
     page.within(all('.group')[1]) do 
      expect(page.find('button')[:title]).to include('BBBBB') 
     end 
     page.within(all('.group')[2]) do 
      expect(page.find('button')[:title]).to include('CCCCC') 
     end 
    end 

    XXX 

    # After change (AJAX polling) 
    page.within(first('.parent')) do 
     page.within(all('.group')[0]) do 
      expect(page.find('button')[:title]).to include('DDDDD') 
     end 
    end 
end 

Cependant, cela ne fonctionne pas. Car expect(page.find('button')[:title]).to include('DDDDD') n'attendra pas jusqu'à ce que l'interrogation AJAX soit exécutée. Si je mets sleep(20) après XXX, ce test a fonctionné, cependant, ce n'est pas Capybara, je suppose.

Je voudrais connaître la manière intelligente de gérer correctement cette situation.

Nous vous remercions de votre aide.

Answer 1

Vous devez utiliser le Capybara fourni matchers, qui ont en attente/comportement réessayant intégré, plutôt que le RSpec fourni include

expect(page).to have_css("button[title='DDDDDD']") 

si vous le voulez pour tester les sous-chaînes en titre, au lieu de l'égalité , vous pouvez utiliser *= plutôt que =, etc.

vous devriez aussi préférer sélecteurs CSS uniques comme find('.group:nth-of-type(1)') plutôt que all('.group')[0] chaque fois que possible (la signification de ces deux expressions sont légèrement différentes, donc il sommetimes suis un y ne peut pas être posssible) puisque les éléments retournés par tous/first ne sont pas rechargeables