سرور مجازی NVMe

تست سرتاسری در جاوا اسکریپت با اتوماسیون تست CypressEnd-to-End بخش مهمی از چرخه عمر توسعه هر برنامه مبتنی بر وب است. مسلماً انتخاب ابزار مناسب برای شما و برنامه شما از اهمیت بیشتری برخوردار است. در این راهنما، نگاهی به آزمایش انتها به انتها با استفاده از Cypress خواهیم داشت. "پایان به انتها» تست اشاره به …

JavaScript (JS)برنامه نویسی

توسط مهران در دی ۲۶, ۱۴۰۲

سرفصلهای مطلب

زمان لازم برای مطالعه: 12 دقیقه

معرفی

اتوماسیون تست سرتاسر بخش مهمی از چرخه عمر توسعه هر برنامه مبتنی بر وب است. انتخاب ابزار مناسب برای شما و برای برنامه شما مسلماً مهمتر است.

در این راهنما، نگاهی به تست انتها به انتها با استفاده از سرو.

“پایان به انتها” تست اشاره به process شبیه سازی تجربه کاربر و تعامل کاربر با یک سرویس، و آزمایش اینکه آیا خطا در آن وجود دارد یا خیر process.

چرا از سرو استفاده کنیم؟

به راحتی بزرگترین مزیت استفاده از Cypress چیزی است که توسعه دهندگان Cypress به آن می گویند “سفر در زمان”.

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

ما بخش قابل توجهی از ادراک شناختی آنها را پایه گذاری می کنیم روی بینایی ما، و “سفر در زمان” به ما این امکان را می دهد که به طور شهودی (انسانی) اشکالات را شکار کنیم، در حالی که همچنان از مزایای اتوماسیون به ما می دهد.

همچنین این یک رویکرد بسیار طبیعی برای جستجوی اشکال است روی این واقعیت که این یک چارچوب متمرکز است روی تست پایان به انتها، به این معنی که به غیر از آزمایش عملکردها، ما در واقع می توانیم آنچه را که کاربر نهایی می بیند، ببینیم.

برخی از دلایل دیگری که ممکن است بخواهید از Cypress استفاده کنید عبارتند از:

مبتنی نیست روی سلنیوم بنابراین مسائل مشابهی ندارد و دیدگاه جدیدی ارائه می دهد. سرو از پایه ساخته شده است.
بیش از حد متمرکز روی تست انتها به انتها.
اگر می توانید آن را در مرورگر اجرا کنید، می توانید آن را با Cypress تست کنید.
شما فقط باید جاوا اسکریپت را یاد بگیرید.
راه اندازی فوق العاده آسان و سریع است.
با در نظر گرفتن توسعه آزمایشی ایجاد شد.
اسناد رسمی فراوان
می‌توانید تک تک درخواست‌های شبکه‌ای را که در نقطه‌ای که از مرورگر انجام شده است، با دسترسی به همه داده‌ها مشاهده کنید.
شما می توانید هر درخواست شبکه را خرد کنید، در حالی که می توانید هر درخواست شبکه ای ایجاد کنید (به این معنی که می توانید از Cypress برای تست API نیز استفاده کنید).
فعال و شفاف توسعه دهندگان.

سرو ساخته شده است روی بالای موکا و چای، که هر دو کتابخانه BDD و TDD مدرن و محبوب هستند و در واقع برخی از نحو را به همین دلیل قرض می گیرند. اگر قبلا با اینها کار کرده باشید، متوجه خواهید شد قلاب سرو مستقیماً از موکا وام گرفته شده است.

چرا از سرو استفاده نمی کنیم؟

هیچ ابزار کاملی وجود ندارد، و با گسترش – هیچ ابزار تست کاملی وجود ندارد. سرو در حالی که عالی است، از این قاعده مستثنی نیست.

بسته به روی نیازهای شخصی یا پروژه شما، برخی از موارد ذکر شده به عنوان مزایا می توانند به معایب تبدیل شوند:

از آنجایی که از سلنیوم استفاده نمی کند و مبتنی بر جاوا اسکریپت است، باید دانش جاوا اسکریپت را داشته باشید. سلنیوم از جاوا اسکریپت، جاوا، پایتون، Ruby و سی#.
از آنجایی که بیش از حد متمرکز است روی آزمایش انتها به انتها، راه حلی نیست که بتوانید برای همه انواع دیگر تست ها (به جز تست API) اعمال کنید.
از همه مرورگرها پشتیبانی نمی کند (و احتمالاً هرگز نخواهد شد) (شما می توانید لیست مرورگرهای پشتیبانی شده را پیدا کنید اینجا) این می تواند یک مشکل باشد زیرا انواع خاصی از مشتریان ممکن است پشتیبانی IE، Opera یا Safari را درخواست کنند.
بدون تست موبایل
هنگام استفاده از پیمایش مستقیم URL، پوسته پوسته می شود.
نمی توان با بیش از یک برگه کار کرد.
نمی توان به یک URL دامنه دیگر پیمایش کرد – اگر بیش از یک برنامه را به عنوان بخشی از راه حل خود داشته باشید یا نیاز به آزمایش چیزی داشته باشید، می تواند یک مشکل بزرگ باشد. روی یک UI شخص ثالث شما باید یک پروژه جداگانه برای برنامه دیگر خود نگه دارید یا کاملاً متکی باشید روی درخواست های شبکه برای واکشی داده ها
نسبتا جدید است، بنابراین به اندازه کافی ندارد انجمن مواد به عنوان برخی از ابزارهای آزمایشی قدیمی وجود دارد.
به نظر می‌رسد برخی از ویژگی‌های نقشه راه برای برخی از اقداماتی که معمولاً در برنامه خود انجام می‌دهید – مانند آپلود فایل، شناور کردن و اسکرول کردن، عقب افتاده‌اند. باید راه حل هایی پیدا کنید.
اگر می خواهید ارتباط مستقیم با پایگاه داده یا تقریباً هر چیزی خارج از کار مستقیم مرورگر را داشته باشید، کار قابل توجهی لازم است. دارند برنامه ریزی می کنند روی با این حال، آداپتورهای بک‌اند را برای زبان‌های دیگر منتشر کرد. این راهنما به محض انتشار به سرعت به روز می شود.

برخی از اینها خواهد شد هرگز تغییر نمی کند در حالی که برخی برای تغییر برنامه ریزی شده اند. اگر جزئیات بیشتری می خواهید روی کدام ویژگی‌ها حفظ می‌شوند و کدام‌ها نه، آنها مبادلات page یک مکان عالی برای شروع است.

نصب و راه اندازی Cypress

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

ما از سینک آشپزخانه برنامه آزمایشی.

توجه داشته باشید: برای کاربران ویندوز، اجرا کنید npm run start:ci:windows برای شروع برنامه

پس از شروع برنامه، بیایید Cypress را با استفاده از آن نصب کنیم npm:

$ npm install cypress --save-dev

در نهایت، می‌توانیم کتابخانه را با استفاده از آن راه‌اندازی کنیم npx یا yarn:

$ ./node_modules/.bin/cypress run open # Directly
$ npx cypress open # Using npx
$ yarn run cypress open # Using yarn

اگر از برنامه آزمایشی استفاده می کنید، قبلاً مشخصات نمونه زیادی خواهید داشت:

کلیک کردن روی هر یک از آنها (مثلا actions.specs.js) رانر را راه اندازی می کند:

Cypress API and Style

سرو ساخته شده است روی بالای Mocha و Chai و برخی از نحو و ویژگی های آنها را به عاریت گرفته است.

یعنی مهمترین عناصر وام گرفته شده عبارتند از describe()، context()، it() specify() مواد و روش ها. آنها اساسا لفاف‌هایی برای روش‌های آزمایش واقعی هستند حاشیه نویسی گروه های آزمایشی با برچسب ها

شایان ذکر است که specify() و it() مترادف هستند، همانطور که describe() و context(). بسته به روی چیزی که برای شما طبیعی تر به نظر می رسد، می توانید از هر ترکیبی از اینها استفاده کنید.

describe() برای دادن زمینه به مجموعه ای از تست ها استفاده می شود، در حالی که it() تست های فردی را شرح می دهد. به طور معمول، آنها را در ساختاری شبیه به این لانه می کنید:

describe("Element X Testing", () => {
    it("Does Y", () => {
        // Test...
    });
    it("Does Z", () => {
        // Test...
    });
});

این هست صرفا تا برای خودمان و سایر توسعه دهندگان، نگاهی گذرا به آنچه در حال انجام است، آسان تر کنیم روی بدون نیاز به گذر از کل زنجیره (بالقوه طولانی) روش های مورد استفاده برای آزمایش چیزی.

در هر آزمون، ما تکیه خواهیم کرد روی نمونه سرو (cy) برای اجرای روش های مختلف مانند visit()، get()، fixture()و غیره و همچنین روش های زنجیره ای برای این نتایج.

این visit() و get() روش‌هایی که معمولاً بسیار رایج هستند، همچنین بیان می‌کنند که عنصر و URL بازدید شده وجود دارد و در صورت عدم وجود خطا، آنها را به‌عنوان تست‌های قبول شده در نظر می‌گیرند. آنها نیز هستند شروع کنید از هر زنجیره، از این رو، آنها به عنوان شناخته شده است والدین مواد و روش ها.

به طور مشابه با ادعای وجود، می توانید بررسی کنید که آیا یک عنصر وجود دارد یا خیر contains() یک ارزش

این exec() متد یک دستور را اجرا می کند روی رابط خط فرمان و request() متد یک درخواست HTTP ارسال می کند.

این type() روش، محتوای متنی را به عناصری وارد می کند که می توانند محتوای متنی را بپذیرند و click() روی یک عنصر انتخاب شده کلیک می کند.

فقط با این چند روش، می توانید کارهای بسیار زیادی انجام دهید، و یک مجموعه تست معمولاً شامل بیشتر این موارد است:

describe("Testing CRUD Form", () => {
    it("Visits the addition page", () => {
        cy.visit('/addProduct');
    });
    it("Gets the input field and inputs text", () => {
        cy.get('.input-element')
          .type('Product 1');
    });
    it("Clicks the 'Add Product' button", () => {
        cy.contains('Add Product')
          .click();
    });
    it("Checks if X was added correctly", () => {
        cy.get('product-title')
          .should('have.value', 'Product 1');
    });
    it("Runs a CLI Command", () => {
        cy.exec('npm run other-service');
    });
    it("Sends POST HTTP request", () => {
        cy.request('POST', '/host/other-service/updateCustomers', { mail: 'Product 1 is out!' })
          .its('body');
    });
});

نحو Mocha مورد استفاده در Cypress بسیار ساده، سرراست و شهودی است. استفاده از describe() و it() بلوک ها به ما این امکان را می دهد که به طور طبیعی در آزمایش ها پیمایش کنیم و آنچه را که انجام می دهند حاشیه نویسی کنیم.

این should() روش متکی است روی اظهارات چای، که نسبتاً شهودی نیز هستند.

در نهایت، هنگامی که برای اجرای تست ها آماده شدید، می توانید اجرا کنید:

$ cypress run --browser chrome

این دستور تمام تست های ثبت شده را تا زمان تکمیل اجرا می کند. بیایید جلو برویم و Cypress را به یک پروژه واقعی اضافه کنیم.

افزودن سرو به پروژه

یک ویرایشگر کد مورد نظر خود را انتخاب کنید و پروژه را باز کنید rootو خود را به آن هدایت کنید /cypress/integration/examples/actions.specs.js برای دیدن کد پشت تمام تست هایی که اجرا می کند.

در حال حاضر هزاران نمونه در اینجا وجود دارد، اما بیایید نمونه خود را ایجاد کنیم spec.js در یک لحظه فایل کنید و کاوش کنید:

پیکربندی (cypress.js) فایل
روش استفاده از فایل های فیکسچر
روش استفاده از دستورات

فایل تنظیمات دوبله شده cypress.js به طور خودکار در پروژه تولید می شود root و به طور پیش فرض فقط حاوی یک مکان نگهدار برای شناسه پروژه شما است:

{	
   "projectId": "yourId"
}

بیایید اضافه کنیم baseUrl کلید، و یک مقدار مناسب به آن اختصاص دهید. از آنجایی که برنامه ما در حال اجرا است روی بندر 8080، زیر localhost به آن اشاره می کنیم:

{
  "projectId": "4b7344",
  "baseUrl": "http://localhost:8080"
}

حالا بیایید یک دایرکتوری جدید در زیر ایجاد کنیم /integration تماس گرفت my_tests و یک فایل به نام tests.spec.js. متوجه خواهید شد که در Cypress از قبل گزینه اجرای این فایل جدید را از شما می خواهد، زیرا به صورت پاسخگو فایل را اسکن می کند. /integration دایرکتوری برای تست های جدید

بیایید جلو برویم و چند تست را در ما تعریف کنیم tests.spec.js فایل:

/// <reference types="cypress" />

/* In general, it is a good practice to store 
 all your selectors in variables, since they 
 might change in the future */
var email;
var emailSelector = '.action-email';

describe('Email Input', () => {
    /* beforeEach() which will run before every 
    it() test in the file. This is great 
    if you want to perform some common actions 
    before each test */
    beforeEach(() => {
        /* Since we defined `baseUrl` in cypress.json,
        using `/` as the value in `cy.visit()` will navigate to it.
        Adding `commands/actions` will add the value to the `baseUrl`. */
        cy.visit('/commands/actions');
        /* We are reading the example fixture file and assigning its
        value to a global variable so it is accessible in every test */
        cy.fixture('example').then((json)=>{
            email = json.email;
        });
    });

    it('Clicks روی Actions, and writes the email from the fixture', () => {
        cy.get(emailSelector)
            .type(email)
            .should('have.value', email);
    });
});

این beforeEach() متد قبل از هر کدام اجرا می شود it() روش. این بدان معنی است که ما می توانیم برخی از وظایف مشترک را در آنجا تنظیم کنیم تا از تکرار آنها در هر یک جلوگیری کنیم it() زنگ زدن. در اینجا، ما به سادگی به آن پیمایش کرده ایم localhost:8080/commands/actions. این visit() متد یک رشته (URL) را برای پیمایش می پذیرد و آن را به آن اضافه می کند baseUrl در فایل پیکربندی تعریف شده است.

علاوه بر این، ما راه اندازی کرده ایم ثابت. فیکسچرها فقط اسناد ثابت هستند (JSON یک فرمت محبوب برای ذخیره داده ها است، به طور طبیعی)، که ما می توانیم از آنها برای تزریق داده ها به آزمایش های خود استفاده کنیم. آنها همچنین معمولاً برای خرد کردن درخواست های شبکه استفاده می شوند.

در اینجا، داده‌های JSON را می‌خوانیم example فایل، واقع در زیر cypress/fixtures/example.jsonو از مقدار استخراج شده برای تخصیص آن به ما استفاده کرد email متغیر.

به این ترتیب، می‌توانیم به جای کار با حروف الفبای رشته‌ای، از ایمیل نمونه در تست‌ها استفاده کنیم.

همانطور که قبلاً اشاره کردیم، get() متد عنصر را با the بازیابی می کند action-email کلاس ما قبلاً این کلاس را به عنوان ذخیره کرده ایم emailSelector متغیر. سپس، ما می نویسیم email از example.json فایل در آن عنصر – به طور موثر آن را وارد کنید.

در نهایت، ما ادعا می کنیم که اقدام از طریق موفقیت آمیز بود چای should() روش. بیایید ادامه دهیم و این تست را اجرا کنیم:

$ cypress run

که منجر به:

پیکربندی متغیرهای جهانی در فیکسچرها

اگر نیاز به دسترسی داشته باشیم emailSelector متغیر بسیار منظم‌تر از این تست‌ها – ممکن است بخواهیم آن را به عنوان یک متغیر جهانی تعریف کنیم. این یک مورد عالی برای استفاده مجدد برای وسایل است که می توانیم به راحتی از طریق آن به آنها دسترسی پیدا کنیم cy.fixture().

بیایید یک فایل JSON جدید در زیر ایجاد کنیم /fixtures دایرکتوری، نامیده می شود selectors.js که شامل تمام انتخابگرهای سطح جهانی برای برنامه ما خواهد بود:

{
 "emailSelector": ".action-email"
}

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

ایجاد روش های سفارشی

علاوه بر این، اگر می خواهید همان را اجرا کنید beforeEach() روی چندین فایل مشخصات – ممکن است بخواهید با اضافه کردن آن به فایل از این افزونگی نیز جلوگیری کنید commands.js فایل. هر روشی که به commands.js فایل به عنوان یک روش سفارشی ثبت می شود که می توانید از طریق آن استفاده کنید cy نمونه، مثال. بنابراین اگر دائما در حال بازدید از commands/actions URL، ما همچنین ممکن است یک روش ایجاد کنیم، مثلاً، navigateToActionsPage() که در سطح جهانی قابل دسترسی است.

این commands.js فایل در زیر قرار دارد /support فهرست راهنما:

Cypress.Commands.add('navigateToActionsPage', () => {
    cy.visit('/commands/actions');
})

به این ترتیب می توانیم اضافه کنیم ن دستورات برای اجرا، و فقط به آنها ارجاع دهید به جای نوشتن دوباره و دوباره. برگردیم به tests.spec.js و کد ما را دوباره انجام دهید تا حذف شود cy.visit() تماس بگیرید و از روش استفاده کنید commands.js فایل:

/// <reference types="cypress" />

var email;
var emailSelector;

describe('Email Input', () => {
    beforeEach(() => {
        // Our method in `commands.js`
        // can now be used from anywhere 
        cy.navigateToActionsPage();
        cy.fixture('example').then((json)=>{
            email = json.email;
        });
        // We can now read the selectors fixture 
        // file and load it into our global variable 
        // to store the selector
        cy.fixture('selectors').then((json)=>{
            emailSelector = json.emailSelector;
        });
    });
    it('Clicks روی Actions, and writes the email from fixture', () => {
        cy.get(emailSelector).type(email).should('have.value', email);
    });
});

ممکن است در حال حاضر تفاوت چندانی به نظر نرسد، اما داشتن پروژه ای که در آن وجود دارد page مثلاً 20 فیلد ورودی دارد که مستعد تغییر هستند به این معنی که داشتن یک فضای متمرکز برای نگه داشتن انتخابگرها برای نگهداری خوب کد ضروری است.

نام مستعار یک درخواست XHR

یک XMLHttpRequest (درخواست XHR) می تواند برای ارسال و بازیابی داده ها از یک صفحه وب، بدون نیاز به بارگیری مجدد استفاده شود. در ابتدا برای انتقال داده های XML ساخته شده بود، اما معمولاً برای ارسال و درخواست داده های JSON به جای آن استفاده می شود، حتی اگر نام آن نشان می دهد فقط برای XML است. این یک سناریوی غیر معمول نیست، زیرا بسیاری از برنامه های کاربردی وب درخواست های مختلفی را ارسال می کنند و پاسخ های ارسال شده به آن درخواست ها را نمایش می دهند. روی یک وب page.

ما می توانیم درخواست های مستعار XHR را برای آزمایش عملکرد آنها از طریق Cypress انجام دهیم. ابتدا، بیایید یک روش سفارشی دیگر را به روش خود اضافه کنیم commands.js فایل تا بتوانیم به عنوان یک متد جهانی به آن دسترسی داشته باشیم و از آن در خود استفاده کنیم beforeEach() قلاب:

Cypress.Commands.add('navigateToAliasingPage', () => {
    cy.visit('/commands/aliasing');
})

بعد، اجازه دهید یک فایل جدید به نام ایجاد کنیم aliasing_tests.spec.js در ما /my_tests فهرست راهنما.

توجه داشته باشید: از طرف دیگر، می‌توانید یک قطعه کد دیگر را نیز اضافه کنید (در داخل a پیچیده شده است describe()) در فایل موجود ما. اگرچه، به طور کلی، حفظ یک ویژگی در یک فایل، ایجاد یک ویژگی جدید در هنگام آزمایش یک ویژگی دیگر، تمرین خوبی است.

ما از آن استفاده خواهیم کرد cy.intercept() و cy.wait() روش‌هایی که در اینجا برای اثبات درخواست‌ها و پاسخ‌های شبکه ساخته شده‌اند. این cy.intercept() این روش برای جاسوسی و خرد کردن درخواست‌ها و پاسخ‌های شبکه استفاده می‌شود و جایگزین آن می‌شود cy.route() روش. از سوی دیگر، cy.wait() روش برای انتظار برای یک زمان ثابت استفاده می شود یا تا زمانی که یک منبع مستعار حل شود.

ما یک درخواست XHR را به آن ارسال خواهیم کرد /comments نقطه پایانی، در انتظار پاسخ و آزمایش آن. این دقیقاً مورد استفاده مناسبی است intercept() (برای خرد کردن درخواست) و wait() (منتظر بمانید تا منبع برگشتی حل شود).

بیایید چند تست را به آن اضافه کنیم aliasing_tests.spec.js فایل:

/// <reference types="cypress" />
context('Aliasing XHR', () => {    
  // Aliasing in beforeEach makes the route aliased in every test in this context    
  beforeEach(() => {        
    // Stub and access any XHR GET request and route to **/comments/*.         
    // The ** and * are wild cards, meaning it could be `/microservice/comments/1`
    // or in our case `https://jsonplaceholder.cypress.io/comments/1`       
    // the `as()` function allows us to later `get()` this route with any valid chainable function
    cy.intercept('GET', '**/comments/*').as('getComment');        
    cy.navigateToAliasingPage();    
  });        
  it('clicks a button and expects a comment', () => {        
    // Clicking this button will create and XHR request that generates a comment        
    cy.get('.network-btn').click()        
    // `wait()` is one of the valid chainable actions where we can use the aliased endpoint
    // `then()` will allow us to access all the elements of the response 
    // for validation whether or not this is available روی UI        
    cy.wait('@getComment').then((getCommentResponse) => {            
      // `getCommentResponse` contains all the data from our response. 
      // You can investigate this in the network tab of your browser            
      // Check that the response code is what we expect            
      expect(getCommentResponse.response.statusCode).to.equal(200);            
      // Check that the `response.body` has a parameter named 'email', equal to a certain value
      expect(getCommentResponse.response.body.email).to.equal('(email protected)');            
      // Perform same check but for the `name` parameter            
      expect(getCommentResponse.response.body.name).to.equal('id labore ex et quam laborum');        
    });    
  });
});

بیایید ادامه دهیم و این تست را اجرا کنیم:

$ cypress run --record --spec "cypress/integration/my_tests/aliasing_tests.spec.js"

که منجر به:

پاسخ های درخواست تمسخر XHR

یکی دیگر از ویژگی های بسیار مفیدی که باید به آن توجه کنید این واقعیت است که می توانید به طور کامل از آن صرف نظر کنید process ایجاد نظر از بخش قبل شما می توانید با استفاده از این درخواست شبکه، پاسخ ساختگی خود را ایجاد کنید cy.intercept(). این زمانی مفید است که بک‌اند هنوز توسعه نیافته باشد، بنابراین می‌توانید پاسخ را قبل از اتمام آن مسخره کنید، یا فقط می‌خواهید فقط این بخش از برنامه را آزمایش کنید.

ما همچنین کاربرد دیگری برای فایل های فیکسچر در اینجا داریم. بیایید یکی به نام ایجاد کنیم mock_comment.json که حاوی داده های مسخره شده یک نظر است و محتوای JSON زیر را اضافه می کند:

{  
  "postId": 1,  
  "id": 1,  
  "name": "My Name",  
  "email": "(email protected)",  
  "body": "My Comment Body"
}

حالا بیایید یک فایل دیگر به نام ایجاد کنیم intercepting_requests.spec.js زیر /my_tests فهرست راهنما. در اینجا، ما همان نقطه پایانی را قطع می‌کنیم، اما فیکسچر خود را به عنوان پاسخ تزریق می‌کنیم، و کاملاً از آن صرفنظر می‌کنیم واقعی درخواست:

/// <reference types="cypress" />
describe('Intercepting XHR', () => {
  beforeEach(() => {       
    // By adding an object `{fixture: 'mock_comment.json'}` in the `intercept()` call,
    // we are telling cypress to use the JSON file as the response.      
    // It can also be aliased using `.as()`.  
    cy.intercept('GET', '**/comments/*',
                 {fixture: 'mock_comment.json'}).as('getComment');       
    cy.navigateToAliasingPage();    
  });        
  it('Clicks a button and expects a comment', () => {        
    cy.get('.network-btn').click()        
    // There is no need to validate the response now since we mocked it,
    // but there is a need to validate the UI        
    cy.fixture('mock_comment').then((json)=>{           
      // We are accessing the comment directly from `mock_comment.json`
      // and checking that the UI is displaying it in its fullest         
      cy.get('.network-comment').should('have.text', json.body);        
    });    
  });
});

بیایید این تست را اجرا کنیم:

$ cypress run --record --spec "cypress/integration/my_tests/intercepting_requests.spec.js"

که منجر به:

نتیجه

Cypress یک ابزار تست نوظهور عالی است. این بسیار سبک وزن و آسان برای راه اندازی، و شگفت انگیز برای TDD، ساخته شده است روی بالای موکا و چای. این امکان را به شما می دهد که به طور کامل بک اند خود را مسخره کنید، که همچنین برای آزمایش قبل از ادغام با بک اند یا در صورتی که بک اند شما هنوز وجود نداشته باشد، عالی است. همچنین می‌تواند در برخی موارد به شکل‌دهی بک‌اند کمک کند، زیرا دقیقاً آنچه را که قسمت جلویی انتظار دارد مشخص می‌کند.

با این حال، اگر به دنبال ابزاری هستید که در مواردی که می‌تواند بسیار انعطاف‌پذیر باشد، و به یک چارچوب بزرگ، شخصی و سفارشی‌شده نیاز دارید، ممکن است بخواهید به سلنیوم بچسبید.

(برچسب‌ها برای ترجمه)# جاوا اسکریپت

منتشر شده در 1403-01-16 03:34:04

امتیاز شما به این مطلب