Protractor: ExpectedConditionsライブラリのelementNotToBeCoveredを実装します

本当にこれが必要です。 それは大きな問題を解決するでしょう

これは、アプリケーションローダーと非同期操作を扱うglobaleaksの問題です。

+1

ページの上部に表示されるポップアップやオーバーレイにはこれが本当に必要ですが、ExpectedConditions.elementToBeClickableはこの場合は役に立ちません...

はい、これ！ 私は常に_ "要素はポイント（x、y）でクリックできません。他の要素はクリックを受け取ります：" _スクロールして要素をクリックしようとすると、エラーが発生します。イライラする。 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は必ずしも十分ではありません。 分度器は、ある要素が見えてはならない別の要素で覆われていると報告することがあります。

たとえば、私のテストの1つでは、リンクがその親divによってカバーされていると報告され、 invisibilityOfは永久に待機します。 toNotBeCoveredByへの欲求を支持する

この号は2年前のものです。 私はそれを見つけることができず、私はまだこの問題に直面しているので、これに対する解決策はすでにありますか？ 私の状況では、カバーする要素がどのポイントでも非表示にならず、視覚的に要素をカバーしていないため、要素が非表示になるのを待つことはできませんが、別の要素がクリックできないため、ポイントでクリックできないというエラーが発生しますクリックを受け取ります。

「toNotBeCoveredBy」の+1

私は次のように1つのケースでそのような問題を解決しました：

"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複数の要素を待つことができます

要素が引き続き表示される場合もありますが、アニメーション後の別の場所に表示されます

開発者がオープンソースプロジェクトに尽力してくれたことに感謝します（できる限り努力します）。

しかし...なぜこれが解決すべき最も重要なデフォルト/ブロック/問題ではないのか私にはわかりません。 アイテムがドームに隠されたり表示されたりするのを待つためにたくさんの睡眠がなければ、テストを書くことはできません。 私は不可視化を待つか可視化を待つかの多くの組み合わせを試しました...しかし、ハッキーハッキーハックハックではないテストを書くことはできません。

なぜ誰もがこの可視性の問題を抱えていないのか理解できません。

これは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';を使用しても機能すると思います。 しかし、いずれにせよ、あなたのアイデアは役に立ちました。 共有していただきありがとうございます。

４年近く経ちますが、これを頂けますか？ この問題を回避するためだけに、インタラクションの間に短いスリープを作成することは非常に不便です。 さらに、 sleepsは、私が（そして多くの人も）避けたいと思う多くの時間を蓄積します。

この問題をシミュレートできるコードを誰かが持っていますか？ 可能であれば、クローンと実行のみを行うためにgithubリポジトリを渡してください。

分度器チームがこれについて何でもできるとはとても思えません。 私には、SeleniumまたはChromedriverのいずれかの問題のように見えます。

• 1

Googleで働いていないため、自分の割り当てを解除する

1つまたは2つの引数を入力として受け取るelemとasync / awaitを使用するヘルパー関数を作成しました。
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)
})