Playwright эсвэл Selenium: 200 тестийн хугацаа 47-оос 19 минут болжээ

ScrollTest-д нийтэлсэн цахим худалдааны багцын хэмжилтэд 200 тест Selenium дээр 47 минут, Playwright дээр 19 минут ажиллаж, долоо хоногийн тогтворгүй тестийн хувь 8.3%-аас 1.4% болжээ. Хоёр багц ижил туршилтын орчинд, зэрэгцээ гүйцэтгэлтэй ажилласан ч энэ нь нэг шилжүүлгийн нийтэлсэн үр дүн юм.

Шинээр E2E тестийн багц байгуулж, динамик интерфэйсийн үйлдлийг тогтвортой шалгах шаардлагатай бол Playwright-ээр эхлэх нь үндэслэлтэй. Харин Selenium тестүүд болон олон машинд ажилладаг Grid аль хэдийн байгуулсан бол шилжүүлэх ажлын өртгийг одоогийн багцаа сайжруулах боломжтой хамт харьцуулж шийднэ. Хугацааны нэг хэмжилтээр аль ч багийн ирээдүйн үр дүнг тогтоох боломжгүй.

Нийт хугацааны зөрүүнд юу багтдаг вэ?

Багц ажиллаж дуусах хугацаа нь браузер дээрх нэг товшилтын хурдтай адил хэмжигдэхүүн биш. Нэвтрэх төлөвийг бэлтгэх, тестийн өгөгдөл үүсгэх, хуудасны хариу хүлээх, ажиллуулагчдыг хуваарилах, алдаа гарсан тестийг давтах зэрэг нь нийлбэр хугацаанд нөлөөлнө. Иймээс нийтэлсэн зөрүүг Playwright-ийн үйлдэл бүр Selenium-ээс хурдан гэсэн дүгнэлт болгон хувиргаж болохгүй.

Шилжүүлгийн явцад тестийн кодын бүтэц ч өөрчлөгдөнө. Тогтмол хугацаагаар түр зогсоодог алхмыг нөхцөл биелэхийг хүлээдэг үйлдлээр солих, давтан нэвтрэлтийг багасгах, зэрэгцээ гүйцэтгэлийг өөрөөр тохируулах нь бүгд нийлбэр хугацааг өөрчилж чадна. Нийтэлсэн хэмжилт эдгээр хүчин зүйлийн тус бүрийн нөлөөг тусад нь тогтоогоогүй тул хугацааны бүх хожлыг зөвхөн framework-д хамаатуулах үндэсгүй.

Тогтворгүй тестийн хувь буурсан нь бас багцын түвшний ажиглалт. Тестүүд ямар алдаанаас болж унаж байсныг мэдэхгүйгээр зөвхөн хүлээлтийн загвар өөрчлөгдсөнөөс ийм үр дүн гарсан гэж хэлэхэд эрт. Гэхдээ энэ үзүүлэлт хугацаатай хамт өөрчлөгдсөн учраас хэрэгсэл сонгохдоо гүйцэтгэлийн хурд болон дахин ажиллуулах шаардлагыг тусад нь авч үзэх шалтгаан болдог.

Хүлээлтийн загвар flaky test-д яаж нөлөөлөх вэ?

Playwright-ийн auto-wait зааварт товшихын өмнө зорилтот элемент харагдах, хөдөлгөөн нь тогтворжих, үйл явдлыг хүлээн авах, идэвхтэй байх нөхцөлийг шалгадаг гэж тайлбарласан. Нөхцөлүүд хугацаандаа биелэхгүй бол үйлдэл алдаагаар дуусна. Энэ нь товч DOM-д орсон даруйд түүнийг дарахаар яарах, эсвэл хөдөлж буй элемент дээр үйлдэл хийхээс үүдэх уралдаант нөхцөлийг багасгадаг.

Жишээлбэл, товч харагдаж байгаа боловч дээр нь түр зуурын давхарга байрласан бол Playwright товшилт тухайн элементэд хүрэхийг хүлээнэ. Шалгах нөхцөлийг үйлдэлтэй нь холбодог тул тест бичигч бүх товшилтын өмнө таамгаар тогтоосон түр зогсолт нэмэх хэрэгцээ багасна. Харин буруу locator, дутуу өгөгдөл эсвэл серверийн алдааг ийм хүлээлт засахгүй; тэдгээрийг тестийн логик болон орчноос нь оношилно.

Selenium-ийн хүлээлтийн заавар нь элемент хайхад үйлчлэх implicit wait болон тодорхой нөхцөлийг давтан шалгадаг explicit wait-ийг ялгадаг. Мөн хоёрыг хольж хэрэглэхэд бодит хүлээх хугацааг таамаглахад бэрх болохыг анхааруулжээ. Тиймээс Selenium багцад flaky test олширвол үйлдэл бүр яг ямар төлөвийг хүлээж байгааг шалгах нь хэрэгсэл солих шийдвэрээс өмнөх бодит сонголт юм.

Энэ ялгаа Selenium хүлээлтгүй гэсэн үг биш. Selenium-д шалгах нөхцөлийг тестийн кодод зориуд илэрхийлэх шаардлага илүү их гардаг бол Playwright олон үйлдлийн бэлэн байдлыг өөрөө шалгана. Аль арга нь тохирохыг багийн одоогийн хүлээлтийн кодын чанар, интерфэйс хэр олон удаа өөрчлөгддөг байдал, алдааг оношлоход зарцуулдаг хугацаа шийднэ.

Браузер ба хэлний шаардлага сонголтыг хэрхэн өөрчлөх вэ?

Playwright Test-ийн суулгах заавар Chromium, Firefox, WebKit хөдөлгүүрийг локал болон CI орчинд ажиллуулах, TypeScript эсвэл JavaScript төслөөр эхлэх боломжийг тайлбарладаг. Бүтээгдэхүүний хэрэглэгчдэд эдгээр хөдөлгүүрийн хамрах хүрээ тохирч, баг нь энэ хэлний орчинд ажилладаг бол тест ажиллуулагч, зэрэгцүүлэлт, тайлангийн тохиргоог нэг багцад төвлөрүүлэхэд амар.

Гэхдээ хөдөлгүүрийн нэр болон хэрэглэгчийн бодит браузерын шаардлага үргэлж ижил биш. Тодорхой хувилбар, үйлдлийн систем, байгууллагын тохируулгатай браузер дээр баталгаажуулах ёстой бол тэр орчныг хоёр хэрэгсэлд хэрхэн ажиллуулахыг тусад нь үзнэ. Хамрах хүрээ таарахгүй байхад нэг багцын хурдны давуу тал сонголтыг дангаараа шийдэхгүй.

Хэлний орчин мөн шилжүүлгийн өртөгт ордог. Java эсвэл Python дээрх Selenium багц олон туслах сан, өгөгдөл бэлтгэх код, багийн дадалтай холбогдсон байж болно. Шинэ тестийг өөр хэлээр бичих боломжтой байсан ч хуучин багцын хөрвүүлэлт нь зөвхөн командын нэр солих ажил биш: шалгалтын утга, locator, өгөгдөл, алдаа тайлбарлах арга хэвээр ажиллах ёстой.

Grid ба CI-ийн өртөг хаанаас үүсэх вэ?

Selenium Grid-ийн албан тайлбар WebDriver командуудыг алсын браузерт чиглүүлж, тестийг олон машинд зэрэг ажиллуулах, браузерын хувилбар болон платформыг хамрах зориулалтыг тодорхойлдог. Ийм дэд бүтэцтэй багийн хувьд сонголт нь тестийн кодоос гадна ажиллуулагч машин, браузерын орчин, CI дахь хуваарилалтыг хамарна.

CI-ийн зардал багц дуусах минуттай шууд тэнцдэггүй. Зэрэгцээ ажиллуулагчийн тоо, машин бүрийн хүчин чадал, браузер бэлтгэх хугацаа, алдаатай тестийг дахин гүйцэтгэх давтамж нийт хэрэглээг өөрчилнө. Богино хугацаанд дууссан багц илүү олон ажиллуулагч шаардвал минутын бууралтаас гарах хэмнэлт багасаж болно; харин давтан ажиллуулах хэрэгцээ цөөрвөл зардалд нэмэлт ашиг гарч болно.

Тогтсон Grid-ийг солиход багийн өдөр тутмын ажиллагаа ч өртөг болно. Тестийг хаана ажиллуулах, бүтэлгүй сессийн мэдээллийг хэрхэн хадгалах, браузерын хувилбарыг яаж шинэчлэх зэрэг асуудлыг шинэ тохиргоонд дахин шийдэх шаардлагатай. Харин Grid огт хэрэггүй шинэ багт одоо ашиглахгүй дэд бүтцийг боломжит ирээдүйн шаардлага гэж урьдчилан байгуулах үндэс бага.

Шинэ төсөл болон хуучин багцад аль нь зохистой вэ?

Шинэ веб төслийн хувьд Playwright-ийн үйлдлийн өмнөх шалгалт, нэгдсэн тест ажиллуулагч, шаардлагатай браузерын хамрах хүрээ нь эхлэх сайн үндэслэл болно. Ялангуяа интерфэйс байнга өөрчлөгдөж, тестэд олон таамагласан түр зогсолт нэмэгдэхээр байвал хүлээлтийн загвар нь кодын засвар үйлчилгээний ачааллыг бууруулах боломжтой. Энэ бол сонголтын үндэслэл болохоос нийтэлсэн багцын хугацаа өөр төсөлд давтагдах амлалт биш.

Сайн ажиллаж буй Selenium багцтай бол одоогийн хөрөнгө оруулалтыг тооцох нь зохистой. Тогтворгүй хэсгийн implicit болон explicit wait, locator, өгөгдлийн хамаарлыг засахад хангалттай байж болно. Харин засварын дараа ч чухал урсгалуудын ажиллах хугацаа, давтан гүйцэтгэл, засвар үйлчилгээний зардал өндөр хэвээр байвал тэдгээр урсгалыг үе шаттай шилжүүлэх үндэслэл хүчтэй болно.

Ингэж ялгахад гол асуулт нь аль хэрэгсэл ерөнхийдөө хурдан бэ гэдгээс илүүтэй тухайн баг ямар асуудлын төлөө төлбөр төлж байна вэ гэдэгт оршино. Шинэ багцад хүлээлтийн код болон анхны тохиргооны ачаалал давамгайлж болно. Хуучин багцад Grid, хэлний орчин, одоо тогтвортой ажилладаг тестүүдийг хөрвүүлэх ажил илүү үнэтэй байж болно. Тиймээс хэрэгслийн сонголтыг нэг нийтлэгдсэн үр дүн бус, багцын нас болон ажиллуулах орчны шаардлага шийднэ.

Мөн уншаарай:

• Playwright эсвэл Cypress: нэг тестийн хурд бус, browser хүрээ ялгарна
• Medium эсвэл Substack: уншсан минут ба 10%-ийн шимтгэл хоёр өөр бизнес бүтээнэ
• Podia эсвэл Thinkific: $1,000-ын борлуулалт 5%-ийн шимтгэлийг ил гаргана