Protractor: Реализуйте elementNotToBeCovered для библиотеки ExpectedConditions

Созданный на 7 июл. 2015  ·  48Комментарии  ·  Источник: angular/protractor

PRs plz! easy untriaged user experience feature request

Самый полезный комментарий

+1

Все 48 Комментарий

Действительно нужно это. Это решило бы большую проблему

Это и есть наша проблема в глобальных пакетах, связанных с загрузчиком приложений и асинхронными операциями.

+1

Это действительно нужно для всплывающих окон и оверлеев, которые появляются вверху страницы, ExpectedConditions.elementToBeClickable в этом случае не помогает ...

Да это! Я постоянно сталкиваюсь с _ "Элемент нельзя щелкнуть в точке (x, y). Другой элемент получит ошибку click:" _ после прокрутки и попытки щелкнуть элемент .. но только примерно в ~ 14% случаев .. раздражающий. Даже ожидание elementVisible или elementToBeClickable не всегда работает.

+1

+1

+1

Я хотел бы, чтобы эта функция была выпущена как можно скорее. Эта проблема так раздражает. Есть ли способ обхода этого?

+1

+1

+1

+1

@sjelin, вы упомянули, что это можно сделать в другом потоке, верно?

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

+1000000000

+999

+2000000

+2000000

+999

+1

+1

+1

+1
РЕДАКТИРОВАТЬ: Тогда извините. Я видел довольно распространенную практику в других странах голосовать по вопросам с помощью +1, и это проблема, которую я много раз проводил при написании тестов транспортира, поэтому мне было бы интересно увидеть, как она реализована. Но я запомню это на будущее.

Пожалуйста, прекратите + {number} к этому PR. Это не помогает ...

Есть новости по этому поводу?
В моем случае я использую следующее для прокрутки элемента в поле зрения, но я знаю, что это не решение для всех вариантов использования, таких как модальные окна и т. Д.

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

На данный момент мы разработали обходной путь. Мы идентифицируем элемент ( id="spinner" ), который «блокирует» элемент, который мы действительно хотим щелкнуть, и просто ждем, пока блокирующий элемент станет невидимым, вот так:
broswer.wait(EC.invisibilityOf($(‘#spinner’)), 5000)

EC.invisibilityOf не всегда достаточно. Иногда транспортир сообщает, что элемент покрыт другим элементом, который не должен быть невидимым.

Например, в одном из моих тестов сообщается, что ссылка покрывается ее родительским div, и invisibilityOf будет ждать вечно. Удовлетворяя желание toNotBeCoveredBy

Этому выпуску 2 года. Есть ли уже какое-либо решение для этого, потому что я не могу его найти и все еще сталкиваюсь с этой проблемой? В моей ситуации я не могу дождаться, пока элемент станет невидимым, потому что закрывающий элемент не будет невидимым в любой момент и визуально не покрывает элемент, но я все равно получаю сообщение об отсутствии кликабельности в точке, потому что другой элемент будет получить щелчок.

+1 за "toNotBeCoveredBy"

Я решил такую ​​проблему в одном случае следующим образом:

"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;

Имя метода и константы зависит от моего варианта использования, но я думаю, что остальное можно использовать более общим способом.

Затем в своем тесте я использую это так:

helper.waitForAngularInRoomAnimationToBeDone();

Дело в том, что в моей ситуации, когда я смотрю на снимок экрана с ошибкой, который фиксирует состояние экрана браузера в момент ошибки, все выглядит нормально, и элемент, который я хочу щелкнуть, виден, но транспортир по-прежнему сообщает, что элемент не доступен для щелчка, потому что другой получит щелчок, и ожидание, когда элемент станет видимым или включенным, не работает, поскольку элемент уже отображается на экране и включен. У меня есть эта проблема в Chrome, и она появляется не каждый раз, только в 20% случаев. Я попробовал приведенный выше код, но у меня он не работает.

@MihailSeykov Я обнаружил, что если есть анимация, снимок экрана может быть сделан ближе к концу анимации, и поэтому похоже, что элемент не виден, хотя на самом деле это так. Вы можете использовать EC.and для ожидания invisibilityOf нескольких элементов, которые могут покрывать этот элемент.

Иногда элемент все еще будет виден, но в другом месте после анимации

Я ценю всю тяжелую работу разработчиков над проектами с открытым исходным кодом (я стараюсь и делаю, когда могу).

Но ... Я действительно не понимаю, почему это не самая важная проблема по умолчанию / блокировка /, которую нужно решить. Я не могу писать какие-либо тесты без кучи сна, чтобы дождаться, пока элементы будут скрыты или видны в dom. Я перепробовал множество комбинаций ожидания невидимости или ожидания видимости ... но не могу написать тесты, которые не являются хакерскими хакерскими хакерскими атаками.

Я не понимаю, почему у всех нет этой проблемы с видимостью.

Этому более 2 лет и до сих пор не исправлено ??! Это действительно ВАЖНО для тестирования без взлома, исправьте его как можно скорее!

Есть ли в этом прогресс? :)
Хотя, наконец, у меня появилось лекарство от моей проблемы

Не могли бы мы высказать свое мнение по этому поводу? Кто-то смотрит на это или это никогда не будет исправлено? Это доставляет массу проблем многим людям ...

Насколько я знаю, этого нет в дорожной карте. Но для того, чтобы попытаться найти решение этой проблемы, было бы неплохо, если бы у нас был пример проекта и пример кода транспортира для «доказательства» истинной проблемы. Это возможно?

Я также много читаю в комментариях о проблеме с прокруткой до элемента и о том, что в некоторых случаях она все еще не работает. Это могло быть связано с тем фактом, что сама прокрутка также требует времени, но, тем не менее, пример проекта был бы очень хорош!

Кто может нам это предоставить?

Я хотел бы добавить, что для меня это тоже проблема номер один с Selenium. Очень раздражает то, что вам нужно встраивать ожидания и т. Д. Для учета анимации.

Я написал небольшой служебный метод проверки, имейте в виду, что он будет щелкать элемент сразу, когда он станет кликабельным:

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);
    });
  }
}

В вашем тестовом коде:

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

Мое обходное решение заключалось в том, что перед тем, как щелкнуть элемент, я удалил из DOM элемент, закрывающий элемент, который я хочу щелкнуть.
await browser.executeScript("arguments[0].remove();", coverElement);

Прошло почти 3 года ... Эта запрошенная функция не решается из _Protractor_?
В наших тестах есть sleep по всему периметру, чтобы учесть анимацию, которая блокирует кликабельность элемента 😞

@nmfernandes Я думаю, что использование arguments[0].style.visibility='hidden'; может быть менее драматичным, но все же работает. Но в любом случае ваша идея помогла. Спасибо, что поделился.

Прошло почти 4 года, можно нам это? Очень неудобно создавать короткие перерывы между взаимодействиями, чтобы обойти эту проблему. Кроме того, sleeps аккумулируют много времени, которого я (и я верю, что многие люди тоже) хотел бы избежать.

У кого-нибудь есть код, где я могу смоделировать эту проблему? Если возможно, передайте мне репозиторий github только для клонирования и выполнения.

Я очень сомневаюсь, что команда Protractor сможет что-нибудь с этим поделать. Для меня это похоже на проблему с Selenium или Chromedriver.

  • 1

Отказ от назначения, потому что я больше не работаю в Google

Я создал для себя вспомогательную функцию usinc async / await, которая принимает 1 или 2 аргумента в качестве входных данных, elem и
retryCount . Что он делает, он пытается щелкнуть элемент каждые 0,5 секунды, и если возникает какая-либо ошибка, он пытается щелкнуть снова, пока не закончится retryCount или не будет нажата кнопка.

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--;   
        }
    }

}

В файле спецификации или там, где вы хотите его использовать:

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

    const someButton = element(by.id("someElementId"));
    clickOnElementWithRetry(someButton)
})
Была ли эта страница полезной?
0 / 5 - 0 рейтинги