کارگاه سرو قسمت سوم: ساختار تست و اجرای تست

درس 3: ساختار تست و اجرای تست

برای هدف این درس، به توضیح تمام پوشه‌ها و فایل‌های پروژه‌ای که می‌توان در Cypress برای نوشتن تست‌ها استفاده کرد نمی‌پردازیم، بلکه فقط به ساختار فایل اصلی آزمون می‌پردازیم. همانطور که گفته شد، سازه های اصلی که ما عمدتا در توسعه تست Cypress استفاده می کنیم عبارتند از:

توصیف کردن(): این به سادگی راهی برای گروه بندی آزمون های ما است. دو آرگومان نیاز دارد، اولی نام گروه آزمایشی و دومی یک تابع callback است. (توجه داشته باشید: متن نوشته() is فقط نام مستعار برای است توصیف کردن()).

آی تی(): ما از آن برای یک مورد آزمایشی فردی استفاده می کنیم. این دو آرگومان نیاز دارد، یک رشته که توضیح می‌دهد تست باید چه کاری انجام دهد، و یک تابع callback که حاوی تست واقعی ما است.

قبل از(): یک بار قبل از همه آزمایشات در بلوک اجرا می شود.

بعد از(): بعد از تمام تست ها در بلوک یک بار اجرا می شود.

قبل از هر(): قبل از هر تست در بلوک اجرا می شود.

بعد از هر(): بعد از هر تست در بلوک اجرا می شود.

.فقط(): برای اجرای یک مجموعه یا آزمایش مشخص، ضمیمه “.فقط“به عملکرد.

.skip(): برای رد شدن از مجموعه یا آزمایش مشخص شده، ضمیمه “.skip()” به تابع. (همچنین می توانید “ایکس” در مقابل آی تی مسدود کردن برای رد شدن از آن)

در مورد ساختار تست بیشتر بخوانید

پس بیایید این را عملی کنیم.

1: پوشه جدید در زیر ایجاد کنید e2e پوشه، آن را برای مثال صدا بزنید introو فایل آزمایشی جدیدی را در زیر آن پوشه ایجاد کنید و آن را برای مثال فراخوانی کنید testStructure.cy.js. کد زیر را در فایل تست بنویسید:

/// <reference types="Cypress" />

describe('Context: My First Test', () => {
  before(() => {
    // runs once before all tests in the block (before all "it" blocks)
  });

  beforeEach('Clear Cookies', () => {
    // runs before each test in the block (before each "it" blocks)
    cy.clearCookies();
  });

  after('Log something after all test runs', () => {
    // runs once after all tests in the block (after all "it" blocks)
    cy.log('we completed this test run!');
  });

  afterEach(() => {
    // runs after each test in the block (after each "it" blocks)
  });

  it('Test 1', () => {
    cy.visit('/automation-practice-form');
    expect(true).to.equal(true);
  });

  it('Test 2', () => {
    expect(true).to.equal(true);
  });

  xit('Test 3', () => {
    expect(true).to.equal(true);
  });

  it.skip('Test 4', () => {
    expect(true).to.equal(true);
  });

  it.only('Test 5', () => {
    expect(true).to.equal(true);
  });
});

توضیح کد:

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

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

در این مثال داریم:

• خالی قبل از هوک (قلاب خالی اجرا نمی شود و سعی کنید آنها را در کد خود نداشته باشید)

• قبل از هر قلابی که کوکی‌های برنامه ما را پاک می‌کند

• بعد از قلابی که وارد سیستم می شود: “ما این آزمایش را کامل کردیم!”

• بعد از هر قلابی که خالی است

• تست 1: که از یک صفحه از برنامه ما بازدید می کند و صحت دارد

• تست 2: یک ادعا که درست است

• تست 3: یک ادعا که درست است (به عنوان نادیده گرفته شده علامت گذاری شده است)

• تست 4: یک ادعا که درست است (به عنوان نادیده گرفته شده علامت گذاری شده است)

• تست 5: یک ادعا که درست است (به عنوان تنها آزمایشی که اجرا خواهد شد مشخص شده است)

با دادن همه اینها، آیا می توانید حدس بزنید که خروجی این تست چه خواهد بود؟

اگر گفتید که دستور اجرا به این صورت خواهد بود:

1. قبل از هر: cy.clearCookies();

2. تست 5: expect(true).to.equal(true);

3. بعد از: cy.log('we completed this test run!');

شما درست می گویید! بنابراین، بیایید آن را ثابت کنیم. شما می توانید این تست را به روش های مختلف اجرا کنید:

• نگاه کن package.json فایل و در دستور ترمینال VS اجرا کنید:

npm run cypress-cli

این برنامه مشتری Cypress را باز می کند و در آنجا می توانید Chrome را انتخاب کنید و آزمایش کنید که می خواهید اجرا کنید. برای توضیح مشتری Cypress به درس 1 مراجعه کنید.

• شما همچنین می توانید برنامه مشتری Cypress را در رایانه خود جستجو کنید و خودتان آن را راه اندازی کنید و نتیجه مشابه روش قبلی را خواهید داشت.

• نگاه کن package.json فایل و در دستور ترمینال VS اجرا کنید:

npm run cypress-headed

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

• نگاه کن package.json فایل و در دستور ترمینال VS اجرا کنید:

npm run cypress-headless

این دستور تست شما را بدون حالت رابط کاربری گرافیکی اجرا می کند، به این معنی که cypress تست را در مرورگر کروم بدون سر انجام می دهد.

هرکسی ترجیحات و دلایل خاص خود را دارد که چرا در حین توسعه آزمایش ها را به این صورت انجام می دهد، اما ساده ترین آنها این است که کلاینت cypress را باز کنید و تست را به صورت دستی در حین توسعه اجرا کنید، تا بتوانید به راحتی آن را اشکال زدایی کنید و آن را دستکاری کنید. بنابراین، بیایید این کار را اکنون انجام دهیم، برنامه cypress cli را باز کنید و با کلیک روی آن تست را اجرا کنید. کدام نتیجه را گرفتید؟

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

2: پس بیایید کمی بازی کنیم و تست خود را ویرایش کنیم. برداشتن .only از آزمون پنجم خود علامت بزنید و دوباره تست را اجرا کنید.

اگر چیزی شبیه به این را در تصویر بالا دریافت کردید، تست را به درستی اجرا می کنید. شما می توانید ببینید که زمانی که ما حذف شد .only نمره از آزمون 5، آزمون های دیگر در نظر گرفته شد. می بینید که تست 3 و 4 حذف شده اند زیرا ما آن را به عنوان رد شده علامت گذاری کرده ایم. حالا بیایید سعی کنیم آنها را نیز فعال کنیم. برداشتن .skip و x در مقابل تست 3 و 4 و حالا تمام تست های شما باید به ترتیبی که نوشته اید اجرا شوند.

/// <reference types="Cypress" />

describe('Context: My First Test', () => {
  before(() => {
    // runs once before all tests in the block (before all "it" blocks)
  });

  beforeEach('Clear Cookies', () => {
    // runs before each test in the block (before each "it" blocks)
    cy.clearCookies();
  });

  after('Log something after all test runs', () => {
    // runs once after all tests in the block (after all "it" blocks)
    cy.log('we completed this test run!');
  });

  afterEach(() => {
    // runs after each test in the block (after each "it" blocks)
  });

  it('Test 1', () => {
    cy.visit('/automation-practice-form');
    expect(true).to.equal(true);
  });

  it('Test 2', () => {
    expect(true).to.equal(true);
  });

  it('Test 3', () => {
    expect(true).to.equal(true);
  });

  it('Test 4', () => {
    expect(true).to.equal(true);
  });

  it('Test 5', () => {
    expect(true).to.equal(true);
  });
});

شما می توانید هر تست را باز کنید و ببینید در حین اجرای آن چه اتفاقی افتاده است و در صورت نیاز اشکال زدایی کنید.

حالا بیایید سعی کنیم در یک آزمون عمداً مردود شویم. برای مثال آزمون دوم را انتخاب کنید و آن را تأیید کنید true برابر است با false. و شما باید چیزی شبیه به این دریافت کنید:

  it('Test 2', () => {
    expect(true).to.equal(false);
  });

می بینید که تست دوم شکست خورده است، Cypress سعی کرد آن را 4 بار اجرا کند (طبق پیکربندی ما، به درس 2، پایان مراجعه کنید). حال اگر آن را به حالت قبل برگردانید، true === true، دوباره می گذرد.

بنابراین، این چگونه در یک سناریوی آزمایشی زندگی واقعی اعمال می شود؟

فرض کنید باید آزمایشی را بنویسید تا ثابت کنید که فیلد ایمیل یک فرم ورود به سیستم درست کار می کند. برای این آزمون معمولاً باید نوعی اعتبارسنجی را آزمایش کنید.

زمینه تست: اعتبار فیلد ورودی ایمیل را در فرم ورود بررسی کنید (این مربوط به شما خواهد بود describe مسدود کردن)

تست 1: بررسی کنید که آیا کاربر می تواند با فرمت ایمیل صحیح وارد سیستم شود (اول it مسدود کردن)

تست 2: بررسی کنید که آیا کاربر قادر به ورود به سیستم در صورت خالی بودن فیلد ایمیل نیست (دوم it مسدود کردن)

تست 3: بررسی کنید که در صورت ناقص بودن ایمیل، کاربر قادر به ورود به سیستم نیست (سوم it مسدود کردن)

… و غیره.

برای این مثال، اگر برنامه شما برخی از کوکی‌ها را ذخیره می‌کند، خوب است پاک کنید تا داده‌های آزمایشی با آزمایش‌های دیگر تداخل نداشته باشند. Cypress باید پس از هر آزمایش به طور خودکار کوکی ها را پاک کند، اما بسته به موضوع آزمایشی شما ممکن است بخواهید خودتان آنها را پاک کنید. تمرین خوب این است که قبل از هر آزمون، هر وضعیت آزمایشی را پاک کنید. نه بعد از در مورد این ضد الگو اینجا بخوانید: ضد الگو قلاب سرو

مثال دیگر، فرض کنید باید برای برخی از فرم‌ها در داخل برنامه خود تست بنویسید، اما برای انجام این کار ابتدا باید وارد شوید. از آنجایی که ورود موضوع آن تست نیست، یک مرحله آماده سازی است، باید آن قسمت ورود را در آن قرار دهید before یا beforeEach قلاب ها یک ویژگی جدید معرفی شده وجود دارد که در آن می توانید از جلسه cypress برای تنظیم داده های تست استفاده کنید: Session.

✏️ تکالیف

با ساختار تست بازی کنید و سعی کنید ترتیب اجرا را حدس بزنید.

فراموش نکنید که تمام کارهایی را که امروز انجام دادید در Github فشار دهید 😉 دستورات git را به خاطر دارید؟ 😉

git add .

git commit -am "add: first test"

git push


بابت نوشتن اولین آزمون خود تبریک می گویم و شما را در درس 4 می بینم!

کد تکمیل شده این درس

اگر چیز جدیدی یاد گرفتید با خرید یک قهوه از کار من حمایت کنید ☕