برنامه نویسی

سه سبک اختیاری برای ادعاهای UI در Cypress

Summarize this content to 400 words in Persian Lang

.contains()

اغلب، من فقط می‌خواهم یک UI را در Cypress اسکن کنم و مطمئن شوم که مجموعه‌ای از برچسب‌های متنی وجود دارد. معمولا عادت من این بوده که این نوع تست ها را اینگونه استایل کنم:

cy.contains(‘element.class’, ‘Element text’)
.should(‘be.visible’);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

من عاشق سادگی هستم cy.contains()و خروجی گزارش این دستور نشان می دهد که برای چه متنی درخواست شده است، اما نه به واضح ترین و قابل مشاهده ترین روش.

.باید()

پس از بررسی کد اخیر، متوجه شدم که یکی از هم تیمی‌ها به درخواستی شبیه به این شکل می‌دهد:

cy.get(‘element.class’)
.should(‘be.visible’)
.should(‘contain.text’, ‘Element text’);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

پس از کمی فکر، متوجه شدم که این کار خروجی بسیار بهتری را در لاگ Cypress runner ایجاد می کند. در اینجا یک اسکرین شات وجود دارد که در آن می توانید ببینید که متن مورد انتظار اکنون برجسته شده است و خواندن آن آسان تر است. این باعث می‌شود که اشکال‌زدایی یک فرآیند بسیار ساده‌تر باشد، زمانی که بازخوردی در مورد متن مورد نظر دریافت می‌کنیم.

انتظار()

با این حال، می‌توانیم حتی فراتر برویم و گزارش دونده Cypress به ما بگوید که کدام رشته مورد انتظار بود و آنچه در واقع پیدا شد

cy.get(‘element.class’)
.should(‘be.visible’)
.invoke(‘text’)
.then((text) => {
expect(text).eq(‘Element text’);
});

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

همانطور که می بینید، این فراهم می کند ثروتمندترین خروجی را به گزارش، نشان می دهد که هر دو مورد انتظار و آنچه پیدا شده است.

این سبک مطمئناً پرمخاطب‌تر است، اما وضوح بیشتر در خروجی گزارش ممکن است ارزش وقت شما را داشته باشد. داشتن سبک ثابت در یک پایگاه کد می تواند ارزشمند باشد، اما من فکر می کنم خوب است که همه این رویکردهای مختلف را با هم ترکیب کنید تا زمانی که تمرکز شما روی اثربخشی آزمون. امیدواریم این مقاله شما را به این فکر کند که چگونه ممکن است در موقعیت‌های خاص بخواهید ورود واضح‌تری داشته باشید و چگونه سبک کد خود را بر اساس نیازهای موقعیتی خود تغییر دهید.

الحاقیه

گلب بهموتوف در ویدیوی خود با عنوان “از اظهارات قوی تر استفاده کنید” در این مورد صحبت می کند:

می بینید که او سبک دوم را با استفاده از a انتخاب می کند .should() ادعا برای برجسته کردن فقط متن مورد انتظار در گزارش. فکر می‌کنم این در واقع بهترین سبک برای بیشتر موارد استفاده است، اما استفاده از گزارش‌های غنی‌تر در مواقعی می‌تواند مفید باشد، به‌ویژه هنگام اشکال‌زدایی یک تست که در حال نوشتن یا اصلاح است.

.contains()

اغلب، من فقط می‌خواهم یک UI را در Cypress اسکن کنم و مطمئن شوم که مجموعه‌ای از برچسب‌های متنی وجود دارد. معمولا عادت من این بوده که این نوع تست ها را اینگونه استایل کنم:

cy.contains('element.class', 'Element text')
  .should('be.visible');    
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

من عاشق سادگی هستم cy.contains()و خروجی گزارش این دستور نشان می دهد که برای چه متنی درخواست شده است، اما نه به واضح ترین و قابل مشاهده ترین روش.

خروجی ورود به سیستم Cypress با استفاده از cy.contains()

.باید()

پس از بررسی کد اخیر، متوجه شدم که یکی از هم تیمی‌ها به درخواستی شبیه به این شکل می‌دهد:

cy.get('element.class')
  .should('be.visible')
  .should('contain.text', 'Element text');
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

پس از کمی فکر، متوجه شدم که این کار خروجی بسیار بهتری را در لاگ Cypress runner ایجاد می کند. در اینجا یک اسکرین شات وجود دارد که در آن می توانید ببینید که متن مورد انتظار اکنون برجسته شده است و خواندن آن آسان تر است. این باعث می‌شود که اشکال‌زدایی یک فرآیند بسیار ساده‌تر باشد، زمانی که بازخوردی در مورد متن مورد نظر دریافت می‌کنیم.

خروجی گزارش Cypress که یک ادعا با .should() را نشان می دهد

انتظار()

با این حال، می‌توانیم حتی فراتر برویم و گزارش دونده Cypress به ما بگوید که کدام رشته مورد انتظار بود و آنچه در واقع پیدا شد

cy.get('element.class')
  .should('be.visible')
  .invoke('text')
  .then((text) => {
    expect(text).eq('Element text');
  });
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

همانطور که می بینید، این فراهم می کند ثروتمندترین خروجی را به گزارش، نشان می دهد که هر دو مورد انتظار و آنچه پیدا شده است.

خروجی ورود به سیستم سرو که یک ادعا را با expect() نشان می دهد

این سبک مطمئناً پرمخاطب‌تر است، اما وضوح بیشتر در خروجی گزارش ممکن است ارزش وقت شما را داشته باشد. داشتن سبک ثابت در یک پایگاه کد می تواند ارزشمند باشد، اما من فکر می کنم خوب است که همه این رویکردهای مختلف را با هم ترکیب کنید تا زمانی که تمرکز شما روی اثربخشی آزمون. امیدواریم این مقاله شما را به این فکر کند که چگونه ممکن است در موقعیت‌های خاص بخواهید ورود واضح‌تری داشته باشید و چگونه سبک کد خود را بر اساس نیازهای موقعیتی خود تغییر دهید.

الحاقیه

گلب بهموتوف در ویدیوی خود با عنوان “از اظهارات قوی تر استفاده کنید” در این مورد صحبت می کند:

https://www.youtube.com/watch?v=HkXx79JE2nU

می بینید که او سبک دوم را با استفاده از a انتخاب می کند .should() ادعا برای برجسته کردن فقط متن مورد انتظار در گزارش. فکر می‌کنم این در واقع بهترین سبک برای بیشتر موارد استفاده است، اما استفاده از گزارش‌های غنی‌تر در مواقعی می‌تواند مفید باشد، به‌ویژه هنگام اشکال‌زدایی یک تست که در حال نوشتن یا اصلاح است.

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا