web-dev-qa-db-fra.com

Comment fonctionne waitForAngularEnabled?

Je suis curieux de savoir comment fonctionne waitForAngularEnabled ()? Bien que cela ne semble pas compliqué, je n'ai pu obtenir de réponses satisfaites nulle part. J'espère donc que quelqu'un m'aidera à me débarrasser.

Mon objectif est de vérifier les critères et de suspendre/verrouiller le test de fonctionnement jusqu'à ce que les critères soient remplis. Voici des cas par exemple.

A. pour interrompre l'exécution du test et attendre que la page soit chargée

    ...
    let theElement = ...;
    browser.waitForAngularEnabled(false);
    browser.wait(protractor.ExpectedConditions.presenceOf(theElement));

B. utiliser browser.wait (), la méthode alternative à des fins similaires avec A

    browser.wait(() => {
        browser.waitForAngularEnabled(false);
        return browser.isElementPresent(by.id('the-element-id'));
    }, timeout); // timeout may not be given

La question est donc:

  1. Que se passera-t-il une fois waitForAngularEnabled (false) invoqué? (une fois les critères remplis ou le délai d'expiration se produit dans mon cas)
  2. Dois-je rétablir waitForAngularEnabled (true) pour continuer les tests normaux?
  3. Si je devais faire, où le mettre?

J'espère obtenir des réponses claires avec un principe de base.

Merci!

protractor
17
firstor

1. Que se passera-t-il une fois waitForAngularEnabled (false) invoqué? (une fois les critères remplis ou le délai d'expiration se produit dans mon cas)

Empiriquement, j'ai trouvé que cela semble amener Protractor à se comporter comme un simple Webdriver. Il n'attend pas Angular angulaire pour "s'installer" (pas de requêtes HTTP en attente ni de mises à jour de vue), ce qui est le comportement de true. Au lieu de cela, si vous utilisez le false, vous devrez utiliser ExpectedConditions ou des approches similaires afin de vérifier les conditions préalables pour exécuter les étapes de test de manière fiable, comme vous le feriez avec un test Webdriver ordinaire.

2. Dois-je rétablir waitForAngularEnabled (true) pour continuer les tests normaux?

Oui. Cependant, j'ai trouvé que dans Protractor 5.1.1 et 5.1.2, que vous utilisiez le flux de contrôle ou non, la dispersion de valeurs waitForAngularEnabled différentes tout au long de vos tests dans la même exécution semble donner des résultats imprévisibles; c'est-à-dire que l'état activé ne suit pas la même sémantique asynchrone que les autres appels Protractor/Webdriver. Jusqu'à présent, ma conclusion est que vous ne pouvez pas mélanger de manière fiable waitForAngularEnabled (false) et waitForAngularEnabled (true) dans la même exécution. Je soupçonne qu'il s'agit d'un bogue Protractor, mais je n'ai pas encore développé de test simple et fiable pour le prouver à l'appui de la soumission d'un problème Protractor. Il y avait un problème peut-être lié ici , maintenant fermé mais incomplètement diagnostiqué.

3. Si je devais le faire, où le mettre?

"Avant", vous effectuez des appels Protractor/Webdriver qui nécessitent de restaurer la sémantique d'attente angulaire. Cependant, comme mentionné ci-dessus, il n'est pas clair que vous pouvez garantir de manière fiable que de tels appels seront réellement effectués dans le contexte du paramètre true.

Si vous devez avoir certains tests qui utilisent false et d'autres true, vous pouvez les exécuter dans des exécutions distinctes (processus séparés; ne les exécutez pas avec les mêmes protractor ou ng e2e commande). Je n'ai rencontré aucun problème lorsque cette approche est adoptée.

20
Will

La réponse marquée est bonne - j'aimerais quand même répondre à votre question avec des détails supplémentaires sur browser.get:

Pour remplacer le comportement par défaut de Protractor pour attendre les appels Angular, nous pouvons désactiver l'attente Angular avec browser.waitForAngularEnabled (false). Pour le reste de la session du pilote, Protractor ne synchronisera pas les appels Angular sauf si Angular wait est activé en utilisant: browser.waitForAngularEnabled (true)).

Mais je recommande d'utiliser directement le pilote enveloppé au lieu de basculer la propriété waitForAngularEnabled qui peut conduire à un script instable. Nous avons eu un problème avec l'exécution de test parallèle (que nous ne voulions certainement pas exécuter de manière séquentielle) - ce qui est évident lorsque tous les tests définissent waitForAngularEnabled simultanément.

Protractor utilise les API de testabilité exposées par les fonctionnalités AngularJS comme $ q, $ timeout et $ html pour synchroniser la page créée par les composants asynchrones AngularJS.

browser.get Lorsque nous appelons la méthode browser.get dans notre script pour naviguer vers une page Web, Protractor utilise la méthode get de Selenium-webdriver pour naviguer vers la page demandée et essaie par défaut de synchroniser la page en utilisant API de testabilité AngularJS.

La stratégie waitForAngular du rapporteur considère que la page actuelle a la bibliothèque AngularJS et appelle la méthode getTestabilityAPI sur l'objet global window.angular.

browser.driver.get Lorsque vous utilisez Protractor avec une application non angulaire sans remplacer le comportement par défaut, nous obtenons une erreur - angular n'est pas défini car, par défaut, Protractor va essayer de synchroniser la page en utilisant la fenêtre. angular qui n'est pas disponible sur la page.

0
Alex Maker