Protractor: Implementieren Sie elementNotToBeCovered für die Bibliothek ExpectedConditions

Brauche das wirklich. Es würde ein großes Problem lösen

Genau dies ist unser Thema in globalenaks, die sich mit Application Loader und asynchronen Operationen beschäftigen.

+1

Brauche dies wirklich für Pop-ups und Overlays, die oben auf der Seite erscheinen, die ExpectedConditions.elementToBeClickable hilft in diesem Fall nicht...

Ja das! Ich stoße ständig auf _"Element ist an Punkt (x,y) nicht anklickbar. Anderes Element würde den Klick erhalten:"_-Fehler nach dem Scrollen und dem Versuch, auf ein Element zu klicken.. aber nur in etwa 14% der Fälle.. frustrierend. Auch das Warten auf elementVisible oder elementToBeClickable funktioniert nicht immer.

+1

+1

+1

Ich möchte, dass diese Funktionalität so schnell wie möglich veröffentlicht wird. Dieses Problem ist so ärgerlich. Gibt es dafür einen Workaround?

+1

+1

+1

+1

@sjelin Sie erwähnen, dass dies in einem anderen Thread möglich ist, oder?

We would address this using document.elementFromPoint and element.getBoundingClientRect pretty easily actually. elementFromPoint isn't totally standard at this point, though it appears to be supported by all browsers. The consistency issue is real though. Donno if we should leave this the way it is or "fix" it

+100000000

+999

+2000000

+2000000

+999

+1

+1

+1

+1
EDIT: Dann tut mir leid. Ich habe es anderswo als ziemlich gängige Praxis angesehen, über Probleme mit einer +1 abzustimmen, und dies ist ein Problem, bei dem ich viele Winkelmessertests geschrieben habe, daher wäre ich daran interessiert, es implementiert zu sehen. Ich werde mir das aber für die Zukunft merken.

Bitte beenden Sie +{number} diese PR. Das hilft nicht...

Gibt es hierzu Neuigkeiten?
Für meinen Anwendungsfall verwende ich Folgendes, um das Element in die Ansicht zu scrollen, aber ich weiß, dass dies nicht für alle Anwendungsfälle wie Modals und dergleichen geeignet ist.

var el = $('.myElement');
browser.executeScript('arguments[0].scrollIntoView()', el.getWebElement());

Wir haben vorerst einen Workaround entwickelt. Wir identifizieren das Element ( id="spinner" ), das das Element "blockiert", auf das wir tatsächlich klicken möchten, und warten einfach, bis das blockierende Element wie folgt unsichtbar ist:
broswer.wait(EC.invisibilityOf($(‘#spinner’)), 5000)

EC.invisibilityOf ist nicht immer genug. Manchmal meldet Protractor, dass ein Element von einem anderen Element bedeckt ist, das nicht unsichtbar sein sollte.

In einem meiner Tests wird beispielsweise gemeldet, dass ein Link von seinem übergeordneten div abgedeckt wird, und invisibilityOf wird ewig warten. Den Wunsch nach toNotBeCoveredBy

Diese Ausgabe ist 2 Jahre alt. Gibt es dafür schon eine Lösung, weil ich sie nicht finden kann und das Problem immer noch auftritt? In meiner Situation kann ich nicht warten, bis das Element unsichtbar ist, da das verdeckende Element an keiner Stelle unsichtbar sein wird und es das Element nicht visuell bedeckt, aber ich erhalte immer noch die Fehlermeldung, dass es an dieser Stelle nicht anklickbar ist, weil ein anderes Element dies tun würde den Klick erhalten.

+1 für "toNotBeCoveredBy"

Ich habe ein solches Problem in einem Fall mit folgendem gelöst:

"use strict";

function elementWithAttributeHasNotValue(htmlElement, attribute, value) {
    return htmlElement.getAttribute(attribute).then((elementAttribute) => {
        return !elementAttribute.includes(value);
    });
}

class Helper {
    waitForAngularInRoomAnimationToBeDone() {
        const inRoomElement = element(by.className("in-room"));

        browser.wait(elementWithAttributeHasNotValue(inRoomElement, "class", "ng-animate"), browser.params.DEFAULT_TIMEOUT_MS);
    }
}

module.exports = Helper;

Der Name der Methode und der Konstanten sind spezifisch für meinen Anwendungsfall, aber ich denke, der Rest könnte allgemeiner verwendet werden.

In meinem Test verwende ich es dann so:

helper.waitForAngularInRoomAnimationToBeDone();

Die Sache ist die, dass in meiner Situation, wenn ich mir den Screenshot des Fehlers ansehe, der den Zustand des Browserbildschirms im Moment des Fehlers erfasst, alles in Ordnung ist und das Element, auf das ich klicken möchte, sichtbar ist, aber Winkelmesser ist es immer noch melden, dass das Element nicht anklickbar ist, weil ein anderer den Klick empfangen würde und darauf warten, dass das Element sichtbar oder aktiviert wird, funktioniert nicht, da das Element bereits auf dem Bildschirm sichtbar und aktiviert ist. Ich habe dieses Problem in Chrome und es erscheint nicht jedes Mal, nur in 20% der Fälle. Ich habe den obigen Code ausprobiert, aber er funktioniert bei mir nicht.

@MihailSeykov Ich habe festgestellt, dass der Screenshot bei einer Animation möglicherweise gegen Ende der Animation aufgenommen wird und es so aussieht, als wäre das Element nicht sichtbar, obwohl es es tatsächlich ist. Sie können EC.and , um auf invisibilityOf mehrere Elemente zu warten, die dieses Element möglicherweise bedecken

Manchmal ist das Element noch sichtbar, aber nach der Animation an einer anderen Stelle

Ich schätze all die harte Arbeit, die Entwickler für Open-Source-Projekte leisten (ich versuche und tue, wenn ich kann).

Aber... Ich kann wirklich nicht sehen, warum dies nicht der wichtigste zu lösende Standard/Block/Problem ist. Ich kann überhaupt keine Tests schreiben, ohne eine Menge Schlaf zu haben, um darauf zu warten, dass Elemente im Dom versteckt oder sichtbar sind. Ich habe viele Kombinationen ausprobiert, um auf Unsichtbarkeit zu warten oder auf Sichtbarkeit zu warten ... aber ich kann keine Tests schreiben, die keine Hacky Hacky Hacks sind.

Ich verstehe nicht, warum nicht jeder dieses Sichtbarkeitsproblem hat.

Das ist mehr als 2 Jahre alt und immer noch nicht behoben??! Es ist wirklich WICHTIG für das Testen mit Hacks, bitte beheben Sie so schnell wie möglich!

Gibt es diesbezüglich Fortschritte :)
Aber ich hatte endlich ein Heilmittel für mein Problem

Können wir dazu bitte ein Feedback geben. Schaut sich das jemand an oder wird es nie behoben? Das bereitet vielen Menschen viele Probleme...

Soweit ich weiß steht das nicht auf der Roadmap. Um jedoch versuchen zu können, eine Lösung für dieses Problem zu finden, wäre es schön, wenn wir ein Beispielprojekt und einen Beispiel-Protractor-Code hätten, um zu "beweisen", wo das eigentliche Problem liegt. Ist das möglich?

Ich lese auch viel in den Kommentaren über das Problem beim Scrollen zum Element und dass es in einigen Fällen immer noch fehlschlägt. Das mag damit zu tun haben, dass das Scrollen selbst auch Zeit braucht, aber ein Beispielprojekt wäre sehr schön!

Wer kann uns das liefern?

Ich möchte hinzufügen, dass dies für mich auch das Problem Nr. 1 ist, das ich mit Selenium habe. Sehr ärgerlich, dass man Wartezeiten etc. einbauen muss, um Animationen zu berücksichtigen.

Ich habe eine kleine Check-Utility-Methode geschrieben. Denken Sie daran, dass sie sofort auf das Element klickt, wenn es anklickbar wird:

import { ElementFinder, promise } from 'protractor';
export let testHelpers = {
  isClickable(el: ElementFinder): promise.Promise<boolean> {
    return new promise.Promise(resolve => {
      let interval = setInterval(() => {
        el.click().then(() => {
          clearInterval(interval);
          setTimeout(() => {
            resolve(true);
          }, 500);
        }, () => { });
      }, 100);
    });
  }
}

In Ihrem Testcode:

import { testHelpers } from '../src/core/e2e/helpers';
describe('App', () => {
  it('should do something', () {
    let btn = $('.cls');
    browser.wait(testHelpers.isClickable(btn), 3000);
  });
});

Meine Problemumgehung bestand darin, vor dem Klicken auf das Element das Element aus dem DOM zu entfernen, das das Element bedeckt, auf das ich klicken möchte.
await browser.executeScript("arguments[0].remove();", coverElement);

Wir sind fast 3 Jahre alt in ... ist dieses angeforderte Feature nicht von _Protractor_ aus lösbar?
Unsere Tests haben überall sleep , um die Animationen zu berücksichtigen, die die Anklickbarkeit von Elementen blockieren 😞

@nmfernandes Ich denke, es könnte etwas weniger dramatisch sein, aber es funktioniert immer noch, arguments[0].style.visibility='hidden'; . Aber auf jeden Fall war deine Idee hilfreich. Danke für das Teilen.

Fast 4 Jahre später, können wir das bitte haben? Es ist sehr unpraktisch, kurze Schlafzeiten zwischen den Interaktionen zu schaffen, nur um dieses Problem zu umgehen. Außerdem häufen sich die sleeps sehr viel Zeit an, die ich (und ich glaube auch viele Leute) vermeiden möchte.

Hat jemand einen Code wo ich dieses Problem simulieren kann? Wenn möglich, übergeben Sie mir das Github-Repository, um nur zu klonen und auszuführen.

Ich bezweifle stark, dass das Winkelmesser-Team etwas dagegen tun kann. Für mich sieht es nach einem Problem mit Selenium oder Chromedriver aus.

• 1

Ich löse meine Zuweisung auf, weil ich nicht mehr für Google arbeite

Ich habe für mich selbst eine Hilfsfunktion erstellt, die async / await verwendet, die 1 oder 2 Argumente als Eingabe akzeptiert, elem und
retryCount . Es versucht, alle 0,5 Sekunden auf ein Element zu klicken, und wenn ein Fehler auftritt, versucht es erneut zu klicken, bis der retryCount abgelaufen ist oder auf die Schaltfläche geklickt wird.

export const clickOnElementWithRetry = async (elem: ElementFinder, retryCount: number = 5) => {

    while (retryCount) {
        try {
            await elem.click();
            retryCount = 0;
        }
        catch (e) {
            if(retryCount === 0)
                throw "Couldn't click element";
            await browser.sleep(500);
            retryCount--;   
        }
    }

}

In der Spezifikationsdatei oder wo immer Sie sie verwenden möchten:

import { clickOnElementWithRetry } from './helpers/';
it('Clicks on some element', async () => {

    const someButton = element(by.id("someElementId"));
    clickOnElementWithRetry(someButton)
})