Protractor: تنفيذ elementNotToBeCovered لمكتبة ExpectedConditions

حقا بحاجة الى هذا. سيحل مشكلة كبيرة

هذا هو بالضبط مشكلتنا في globaleaks التعامل مع أداة تحميل التطبيق والعمليات غير المتزامنة.

+1

حقًا في حاجة إلى هذا للنوافذ المنبثقة والتراكبات التي تظهر أعلى الصفحة ، فإن ExpectedConditions.elementToBeClickable لا يساعد في هذه الحالة ...

نعم هذه! أواجه باستمرار _ "العنصر غير قابل للنقر عند النقطة (س ، ص). سيتلقى عنصر آخر النقرة:" _ أخطاء بعد التمرير ومحاولة النقر فوق عنصر .. ولكن فقط مثل حوالي 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

هذه القضية عمرها سنتان. هل هناك أي حل لهذا بالفعل ، لأنني لا أستطيع العثور عليه وما زلت أواجه هذه المشكلة؟ في وضعي لا يمكنني الانتظار حتى يصبح العنصر غير مرئي ، لأن عنصر التغطية لن يكون غير مرئي في أي وقت ولا يغطي العنصر بشكل مرئي ، لكنني ما زلت أتلقى الخطأ لعدم قابلية النقر عليه عند النقطة ، لأن عنصرًا آخر تلقي النقر.

+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 عناصر متعددة قد تغطي هذا العنصر

في بعض الأحيان سيظل العنصر مرئيًا ، ولكن في مكان آخر بعد الرسوم المتحركة

أنا أقدر كل العمل الشاق الذي يبذله مطورو المشاريع مفتوحة المصدر (أحاول وأفعل عندما أستطيع).

لكن ... لا يمكنني حقًا معرفة سبب عدم كون هذه المشكلة الافتراضية / الحظر / المشكلة الأكثر أهمية التي يجب حلها. لا يمكنني كتابة أي اختبارات على الإطلاق بدون مجموعة من النوم لانتظار العناصر لتكون مخفية أو مرئية في دوم. لقد جربت العديد من التوليفات لانتظار الاختفاء أو انتظار الرؤية ... لكن لا يمكنني كتابة اختبارات ليست اختراقًا متطفلًا.

لا أفهم لماذا لا يعاني الجميع من مشكلة الرؤية هذه.

هذا أكثر من عامين ولم يتم إصلاحه بعد ؟؟! من المهم حقًا اختبار الاختراقات ، يرجى إصلاحها في أسرع وقت ممكن!

هل هناك أي تقدم في ذلك :)
على الرغم من أنني تمكنت أخيرًا من علاج مشكلتي

هل يمكننا من فضلك الحصول على بعض ردود الفعل على هذا. هل هناك من ينظر إليه أم أنه لن يتم إصلاحه أبدًا؟ إنه يسبب الكثير من المشاكل لكثير من الناس ...

بقدر ما أعرف أنه ليس على خارطة الطريق. ولكن لكي تكون قادرًا على محاولة إيجاد حل لهذه المشكلة ، سيكون من الجيد أن يكون لدينا مثال لمشروع ومثال على رمز منقلة "لإثبات" مكان المشكلة الحقيقية. هل هذا ممكن؟

أقرأ أيضًا كثيرًا في التعليقات حول مشكلة التمرير إلى العنصر والتي لا تزال تفشل في بعض الحالات. قد يكون لهذا علاقة بحقيقة أن التمرير نفسه يستغرق أيضًا وقتًا ، ولكن بعد قولي هذا ، سيكون مثالًا للمشروع رائعًا جدًا!

من يستطيع أن يزودنا بذلك؟

أود أن أضيف ذلك بالنسبة لي ، فهذه أيضًا هي المشكلة رقم 1 التي أواجهها مع السيلينيوم. إنه أمر مزعج للغاية حيث يتعين عليك إنشاء فترات انتظار ، وما إلى ذلك لحساب الرسوم المتحركة.

لقد كتبت طريقة أداة صغيرة للتحقق ، ضع في اعتبارك أنه سينقر على العنصر فورًا عندما يصبح قابلاً للنقر:

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 يراكم الكثير من الوقت الذي أود (وأعتقد أن الكثير من الناس أيضًا) تجنبه.

هل لدى أي شخص رمز يمكنني من خلاله محاكاة هذه المشكلة؟ إذا كان ذلك ممكنًا ، مررني إلى مستودع جيثب للاستنساخ والتنفيذ فقط.

أشك بشدة في أن فريق Protractor يمكنه فعل أي شيء حيال ذلك. بالنسبة لي ، يبدو الأمر وكأنه مشكلة مع السيلينيوم أو Chromedriver.

• 1

ألغِ تعيين نفسي لأنني لم أعد أعمل لدى Google

لقد أنشأت دالة مساعدة usinc غير متزامن / انتظر لنفسي تأخذ 1 أو 2 وسيطة كمدخل ، elem و
retryCount . يحاول ما يفعله النقر فوق عنصر كل 0.5 ثانية وإذا تم إلقاء أي خطأ فإنه يحاول النقر مرة أخرى حتى نفاد عدد مرات المحاولة أو النقر فوق الزر.

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