Comment @CacheLookup travail dans WebDriver?

Je ne suis pas sûr que je comprends le principe de la mise en cache :

@CacheLookup
@FindBy(how = How.ID, using = namespace + signifLvl)
private WebElement sigLvl;

Si nous utilisons cette Annotation façon, ElementLocator est utilisé et que la première fois, un reporter sur le terrain, l'élément est trouvé driver.findElement(by) et de la mise en cache par ElementLocator, de sorte que la prochaine fois que nous y référer, il est retourné à partir du cache.

Il semble qu'il dépend de la durée de vie de la ElementLocator & PageObject instance.

Aussi il ne concerne pas directement driver.findElement(By); appels.

Je suis en supposant, que WebElement est comme un pointeur/référence à l'élément, à droite ? De sorte que si l'élément changements dans le navigateur, il est réfléchi à la WebElement tout de suite. Comme il est en JavaScript. Parce que tous les RemoteWebElement méthodes concernant l'élément de l'état de l'exécution de la commande/demande de navigateur.

De sorte que les modifications sont reflétées même dans l'élément en cache, de droit ?

OriginalL'auteur lisak | 2011-06-02

  1. 9

    Page d'Usine fonctionne sur le principe de configuration des serveurs proxy lorsque la Page de l'Usine est initialisé et chaque fois que vous utilisez un WebElement il va aller à la recherche de l'élément.

    Maintenant ce cachelookup n'est-il stocke les éléments ayant @cachelookup annotation appliqué sur celui-ci et puis les magasins cet élément de référence/s.
    Par exemple:

      public class SearchPage {
 //The element is now looked up using the name attribute,
  //and we never look it up once it has been used the first time
  @FindBy(how = How.NAME, using = "q")
  @CacheLookup
  private WebElement searchBox;
  public void searchFor(String text) {
  //We continue using the element just as before
   searchBox.sendKeys(text);
  searchBox.submit();
   } }

    Ce que cette annotation n'est-il stocke la valeur de la "searchBox" élément et maintenant, il n'est pas nécessaire à la recherche de cet élément sur la page de nouveau.

    OriginalL'auteur Khyati Sehgal

  2. 3

    À mon humble avis, la question devrait plutôt être : Quel est l'élément id pointeur est sur ?

    Comme WebElement n'est pas un état, seules les méthodes qui appellent navigateur. @CacheLookup n'est qu'un raccourci pour public WebElement el = driver.findElement(By); lors de l'initialisation de WebDriver est PageObject, par exemple.

    Après vous avez l'instance, vous êtes l'exécution de ses méthodes, que l'appel du navigateur.

    La WebElement ID correspond à un JS élément de l'instance. si vous allez de ce genre sur le client JS :

    var node1 = document.createElement('a');

    et ensuite ajouter quelque part, pour l'enlever de là, ajouter un endroit autre, etc. et c'est toujours le même node1 exemple, la WebElement exemple toujours des points à l'node1 élément, parce que c'est la même JS nœud instance.

    OriginalL'auteur lisak

  3. 1

    Je sais que cette réponse est la fin de la partie. J'ai essayé de comprendre, @Cachelookup moi-même et est venu avec un certain nombre de tests et conclusions. Ce sujet est difficile à expliquer en bref ici. Merci donc de prendre un coup d'oeil à l'article qui essaie de comprendre le fonctionnement interne de @CacheLookup et également des améliorations de performances que nous obtenons à l'aide de cette annotation. L'Article est sur ToolsQA ici

    OriginalL'auteur virusrocks