დაელოდეთ შედეგს და არა საათს

პარამეტრების ფორმა ნელა ინახავს. ვიღაც ამატებს ორ წამიან პაუზას წარმატების შეტყობინების შემოწმებამდე. ის გადადის მათ ლეპტოპზე. მომდევნო CI გაშვებას ცოტა მეტი დრო სჭირდება და მარცხდება. სხვა დეველოპერი ცვლის პაუზას ხუთ წამამდე. ტესტი ახლა უფრო ნელია, მაგრამ მისი გაგრძელების მიზეზი ჯერ კიდევ არ არის დაკარგული.

სასარგებლო კითხვა არ არის რამდენი წამი დავიძინოთ. ეს არის ის, რაც მტკიცებულებებს ამტკიცებს, რომ შემდეგი ნაბიჯი მზად არის. ეს სახელმძღვანელო აყალიბებს მცირე შენახულ პარამეტრების შემოწმებას ამ კითხვის გარშემო, Playwright-ის მტკიცების დოკუმენტაციის და მისი საუკეთესო პრაქტიკის სახელმძღვანელო გამოყენებით. სკრინშოტი არის საილუსტრაციო ადგილობრივი დემო ვერსია და არა მომხმარებლის აპლიკაცია ან პროდუქტის საორიენტაციო ნიშანი.

პაუზა გამოცნობს. მდგომარეობა ამოწმებს.

დემო ვერსიაში შენახვაზე დაწკაპუნებით ცვლის სტატუსის ელემენტს შენახვადან შენახულზე დაგვიანების შემდეგ. დაუყოვნებელი ხილვადობის შეკითხვა იღებს აწმყოს სურათს. ის არ ელოდება მომავალ მდგომარეობას. Playwright-ის ვებ-პირველი მტკიცებულებები არაერთხელ ამოწმებს ლოკატორს, სანამ მოსალოდნელი მდგომარეობა არ შენარჩუნდება ან მათი ვადა ამოიწურება.

შეადარეთ ორი მიდგომა ტესტში, სადაც გვერდი უკვე ნავიგაციაა თქვენს დადგმის პარამეტრების ფორმაში:

// A fixed delay does not express the requirement.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await page.waitForTimeout(2000);
expect(await page.getByRole('status').innerText()).toBe('Saved');

// The expected state controls when the check finishes.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await expect(page.getByRole('status')).toHaveText('Saved');

ეს არის ალტერნატიული ფრაგმენტები და არა ინსტრუქციები ორჯერ დააწკაპუნოთ ერთ ტესტში. მეორე მტკიცება შეიძლება დასრულდეს როგორც კი გამოჩნდება Saved. თუ ის არასოდეს გამოჩნდება, მტკიცება წარუმატებელია და არა განუსაზღვრელი ვადით ლოდინის ნაცვლად. ნაგულისხმევი მტკიცების ვადა არის ხუთი წამი მიმდინარე მტკიცების დოკუმენტაციის მიხედვით; აირჩიეთ ლოკალური ვადა მხოლოდ მაშინ, როდესაც თქვენი პროდუქტის მოსალოდნელი ქცევა ამართლებს მას.

ავტომატური ლოდინი არ არის იგივე, რაც შედეგის მოლოდინი

Playwright ამოწმებს ქმედუნარიანობას ისეთი მოქმედებების წინ, როგორიცაა დაწკაპუნება. ღილაკს შეიძლება დასჭირდეს იყოს ხილული, სტაბილური, ჩართული და შეუძლია მიიღოს მოვლენები. ეს პასუხობს, შეიძლება თუ არა დაწკაპუნება მოხდეს. ეს არ ადასტურებს, რომ შენახვის მოთხოვნა დასრულდა ან სერვერმა შეინარჩუნა ახალი პარამეტრი.

წარმატების სტატუსი შეიძლება იყოს გონივრული მზადყოფნის პირობა UI-ს შემდეგი ნაბიჯისთვის, მაგრამ ეს არ არის გამძლეობის დამოუკიდებელი მტკიცებულება. შეინახეთ ეს სამუშაოები ცალკე: დაელოდეთ Saved-ს, გადატვირთეთ პარამეტრების გვერდი და გადაამოწმეთ არჩეული მნიშვნელობა. ჩვენი ადრინდელი სტატია დამოუკიდებელი შედეგების შესახებ განიხილავს ამ მტკიცებულების ზღვარს; ეს სახელმძღვანელო ყურადღებას ამახვილებს სინქრონიზაციის მექანიზმზე, რომელიც საიმედოდ მიგიყვანთ შემოწმებაზე.

await expect(page.getByRole('status')).toHaveText('Saved');
await page.reload();
await expect(page.getByLabel('Display name')).toHaveValue('Demo user');

მაგალითი ითვალისწინებს ხელმისაწვდომ ველს სახელად Display name და გადატვირთვის უსაფრთხო დადგმის ჩანაწერს. განსაზღვრეთ ეს კონტრაქტები დემოში ან თქვენს აპლიკაციაში. არ შეცვალოთ ცოცხალი მომხმარებლის პროფილი, რომ დროის ექსპერიმენტი მოსახერხებელი იყოს.

როცა ლოდინი ვერ ხერხდება, ჯერ არ გაბეროთ

ვადაგასული განცხადების ვადა არის მტკიცებულება შესამოწმებლად. სტატუსი შესაძლოა არასოდეს განახლდეს. ტესტი შესაძლოა მიზნად ისახავდეს ძველ კომპონენტს. შენახვა შეიძლება ვერ მოხერხდეს. ან პროდუქტს შესაძლოა ლეგიტიმურად უფრო მეტი დრო დასჭირდეს, ვიდრე მიმდინარე მოლოდინი. შეამოწმეთ მოქმედება და შედეგად მიღებული ინტერფეისი, სანამ შეცვალეთ დრო.

Playwright-ის მოქმედების გზამკვლევი განმარტავს, რომელი ქმედებები ელოდება და რომელი მტკიცებები ხელახლა სცადეთ. ზოგადი თანასწორობის შემოწმებები არ იძენს ამ ქცევას მხოლოდ იმიტომ, რომ მოსალოდნელი ღირებულება ზის მათში. უპირატესობა მიანიჭეთ ლოკატორის მტკიცებას UI-ის ცვალებად პირობისთვის; გამოიყენეთ შემოსაზღვრული კენჭისყრის მტკიცება, როდესაც მდგომარეობა ამ ფორმის მიღმაა.

მოერიდეთ ყოველი წარუმატებლობის უფრო დიდ საერთო დროში გადაქცევას. გრძელი ჭერი მალავს სიმპტომებს და შეიძლება გატეხილი სირბილი გაცილებით მეტხანს გაგრძელდეს. ჩაწერეთ მზადყოფნის სიგნალი და ვინ ფლობს მას. თუ სიგნალი არ არის, უფრო მკაფიო ჩატვირთვის მდგომარეობა ან სატესტო კონტრაქტი შეიძლება უკეთესი გამოსავალი იყოს, ვიდრე სხვა ძილი.

მიმოხილვის ბარათი გენერირებული ტესტებისთვის

ყოველი დროისადმი მგრძნობიარე ნაბიჯისთვის, ჩაწერეთ მოქმედება, მზადყოფნის მდგომარეობა, დროის ამოწურვის მიზეზი და საბოლოო შედეგის შემოწმება. ჩვენს დემო ვერსიაში: შენახვა, სტატუსი უდრის შენახულს, შეთანხმებული შენახვის საპასუხო ფანჯარა, შემდეგ ველი რჩება გადატვირთვის შემდეგ. ამ პატარა ბარათის გადახედვა უფრო ადვილია, ვიდრე პაუზების გროვა.

AnyTest აღწერს აგენტებს, რომლებიც იკვლევენ ვებ აპს და ქმნიან ბოლომდე ტესტებს ადამიანის განსახილველად. თუ გენერირებული ნაკადი ძალიან სწრაფი ან არასანდო ჩანს, მიმომხილველმა უნდა იკითხოს, რა ხდის თითოეულ გადასვლას მზად. ეს არის მიმოხილვის პრინციპი და არა პრეტენზია, რომ AnyTest ავლენს Playwright პარამეტრებს ან გენერირებულ კოდს კონკრეტულ ფორმატში.

ერთი QA ინჟინერი სარგებლობს, როდესაც სინქრონიზაციის წესები საკმარისად მკაფიოა დეველოპერებისთვის შესანარჩუნებლად. გუნდს სპეციალური QA-ის გარეშე შეუძლია გამოიყენოს იგივე ბარათი კოდის განხილვისას. მიზანი არის გამოცდა, რომელიც ელოდება სწორ მიზეზს, მარცხდება სასარგებლო საზღვრებით და არასოდეს ცდება პაუზა მტკიცებულებად.