A Playwright 1.64-es verziója számos olyan új funkciót és finomítást hozott, amelyek megkönnyítik az elemkeresést, a tesztek futtatását, valamint a videófelvételek testreszabását.
1. Új Locator API: locator.within()
A locator.within() segítségével két már létező locatort lehet természetes módon kombinálni, és a relatív pozicionálók (pl. .first(), .nth()) a szülő elemen belül értékelődnek ki.
TypeScript
// Összekapcsol két külön definíciótconstdialog=page.getByRole('dialog');constsaveButton=page.getByRole('button',{ name:'Mentés'});// Mentés gomb keresése kifejezetten a párbeszédablakon belülawaitsaveButton.within(dialog).click();
2. Véletlenszerű tesztfuttatás: --shuffle
Segít kiszűrni a tesztek közötti rejtett függőségeket a futtatási sorrend megkeverésével. A tesztfutás végén megadott seed kód segítségével pontosan reprodukálható a hibás futási sorrend.
Míg a 1.63-ban megjelent zárolások csak egyes tesztekre vonatkoztak, a 1.64-ben már egész fájlokra vagy tesztcsoportokra (describe) is alkalmazhatóak. Az azonos zárolási névvel rendelkező tesztek nem futnak párhuzamosan.
TypeScript
import {test} from '@playwright/test';// Az ebben a csoportban lévő tesztek nem futnak párhuzamosan más 'user-settings' zárral ellátott tesztekkeltest.describe.configure({ lock:'user-settings'});test('profil frissítése',async({page})=>{// ...});
4. default: false beállítás a projekt konfigurációban
A playwright.config.ts-ben megjelölhetők olyan böngészők vagy projektek, amelyeket alapértelmezetten ki szeretnél hagyni a sima npx playwright test futtatásból anélkül, meglévő konfigurációkat kellene törölni.
A Playwright kiegészült a böngésző alapú AI modellek eszközeinek (WebMCP) tesztelésére szolgáló felülettel (page.webmcp.tools() és page.webmcp.callTool()), amellyel ellenőrizhetők az oldalak által az AI-ágensek felé regisztrált eszközök.
Fontosabb breaking change-ek / Viselkedésbeli változások
Rejtett iframe-ek: A nem látható iframe-ben lévő elemeket (pl. visibility: hidden) a Playwright mostantól automatikusan rejtettként kezeli az akciók és a toBeVisible() ellenőrzések során.
Emulált képernyőméret: A devices['Desktop Chrome'] típusú eszközleírók átadják a screen tulajdonságot, így a window.screen felbontása és a media query-k az emulált kijelzőméretet tükrözik.
Snapshot frissítés: A --update-snapshots=missing opció használata esetén a hiányzó screenshotok létrehozása után a teszt sikeresként értékelődik.
Hol is kezdjem? Ma is elégettem nem kevés tokent, bár szerencsére ezek ingyen vannak/voltak. Amit ki akartam próbálni, hogy telepítettem egy Rider-t, ami egy IDE, és nekem a .net miatt van rá szükség, majd pedig a Copilot-tal és Gemini-vel elkezdtem ebből egy Playwright, Nunit és .net projectet faragni. Aztán jött a szokásos nehézség, kell egy jelentést generáló eszköz, ami többet vagy épp másképpen tud, mint az Allure. Az AI azt mondta, hogy Report Portal.
Nem volt mit tenni, elkezdtem belefaragni ezt, és az API kulcs generáláson kívül minden lépést az AI CLI-on keresztül csináltam meg. Szerintem elég pofás lett a végeredmény, de majd erről egy másik bejegyzésben írok részletesebben.
Most inkább megmutatom, hogy mit tud a Report Portal.
Mit mond a Gemini?
A ReportPortal egy nyílt forráskódú (Open Source), AI-alapú tesztriportáló és analitikai platform. Elsősorban automatizált tesztek eredményeinek gyűjtésére, vizualizálására és elemzésére szolgál.
Főbb jellemzők és előnyök
Központi dashboard: Egységes felületen gyűjti össze a különböző tesztkeretrendszerekből és CI/CD csatornákból származó teszteredményeket.
AI / Machine Learning alapú hibaelemzés: A korábbi futtatások alapján automatikusan felcímkézi a hibákat (pl. termékhiba, teszthiba, infrastruktúra-probléma), így drasztikusan csökkenti a manuális triázsolásra fordított időt.
Valós idejű analitika: A tesztek futása közben élőben láthatók az eredmények, trendek és statisztikák.
Integrációk: Szorosan együttműködik hibakövető rendszerekkel (Jira, Rally, Redmine) és CI/CD eszközökkel (Jenkins, GitLab CI, GitHub Actions).
A ReportPortal architektúrája
A ReportPortal mikroszolgáltatás-alapú architektúrát használ, amely több konténerből áll (API Service, UI, Index Service/AI Engine, PostgreSQL, RabbitMQ, OpenSearch/Elasticsearch). Ezért a legegyszerűbb és legajánlottabb módja a lokális futtatásnak a Docker / Docker Compose.
Megkésve, de törve nem, én is elkezdtem egyre több dologra használni az AI-t, ahogy az a korábbi bejegyzéseimből is látszik. Reggel gondoltam egy merészet, és megkértem a Copilot-ot, hogy kezdjünk el csinálni egy Playwright, TypeScript projectet, mindezt VSCode-ban, és csak CLI-jal. Meg kell mondjam, egész jól sikerültek az alapok, és időben is lényegesen hamarabb készült el, mintsem, ha kézzel kezdem el.
Felbuzdulva ezen, megkértem, hogy integrálja bele az Allure riport készítést, ami elsőre nem volt teljes siker, mert nem tartalmazta a korábbi futásokat a kérésem ellenére, de ez is hamar javítva lett.
Folytattam azzal, hogy egy ingyenes és publikus API hívásra írattam vele 3 tesztet, majd pedig kértem, hogy legyen 2 negatív is, amit ő elsőre úgy értett, hogy átírta a meglévőket. Ezt is hamar javítottuk.
Kértem, hogy amit csináltunk, azt tegye bele egy Word fájlba, illetve még készítettem vele egy readme.md fájlt is. Szerintem egész jól sikerült, mindezt relatív kevés idő alatt, szóval biztosan fogom még folytatni vele a munkát.
Íme a teljes lista:
Project path: D:\Repositories\ai-playwright Earliest retrievable project record: approximately 08:55 local time (06:55 UTC)
08:53 ? Initial workspace session
Opened the working area under D:\Repositories.
08:55 ? Created the Playwright project
Created D:\Repositories\ai-playwright as a TypeScript Playwright project.
Configured Chromium, added example tests and a GitHub Actions workflow.
Installed dependencies and Chromium.
Verified that the two starter tests passed with npx playwright test.
09:01 ? Changed reporting to Allure
Switched the default Playwright reporter to Allure.
Added Allure report generation and execution-history persistence.
Updated package.json, playwright.config.ts, .github/workflows/playwright.yml, .gitignore, and scripts/allure-history.js.
Configured CI to restore and save Allure history.
Verified the initial tests and report generation.
09:07?09:23 ? Opened and fixed Allure history
Generated allure-report and started it with npm run allure:open.
Investigated why previous executions were not visible.
Fixed the issue by clearing old result files before each run while preserving history.
Verified that the report showed three executions per test instead of treating earlier executions as retries.
09:26 ? Added Open-Meteo API tests
Added tests in tests/open-meteo-api.spec.ts.
Covered a valid forecast request, invalid latitude, and invalid longitude.
All three tests passed.
09:28?09:34 ? Regenerated the report and improved assertions
Regenerated Allure with the API tests.
Added descriptive failure messages to the expect assertions.
09:49?09:51 ? Added more negative API scenarios
Added a request missing required longitude.
Added a request with an unsupported current-weather variable.
The API test file reached five tests total.
09:52 ? Verified all tests
Ran the full suite.
All seven tests passed.
Regenerated the Allure report with all tests.
09:55?10:03 ? Fixed Allure generation in GitHub Actions
Investigated why the report was not generated in CI.
Updated the workflow to restore history, run Playwright, always generate the report, and upload the report artifact when possible.
Local verification passed.
10:07?10:12 ? Discussed opening reports from CI
Clarified that GitHub Actions cannot directly open a browser on the runner.
Discussed GitHub Pages as the way to automatically host and view the report.
Explained how to open a downloaded report locally with npx allure open.
10:20 ? Opened the Allure report again
10:31 ? Added Playwright Codegen
Added the codegen script to package.json.
Usage: npm run codegen — https://example.com.
Discussed saving recorded tests with –output tests/recorded.spec.ts.
10:34?10:48 ? Reviewed the project and exported coverage
Explained that the project is a Playwright test project, not the application under test.
Identified that baseURL and webServer are not configured.
Created D:\Repositories\ai-playwright\test-coverage.xlsx.
The workbook contains all seven test cases, behaviors, assertions, Allure statuses, and a test-scope coverage summary.
Note: The earliest project-creation record available is the summarized 08:55 local-time session; the initial setup session does not contain a complete message-by-message transcript.
10:56 – Added project README documentation
Created README.md in the project root.
Documented prerequisites and installation from scratch.
Documented browser and API test execution.
Documented Allure report generation, opening, and execution-history handling.
Documented Playwright Codegen usage.
Documented project configuration, structure, GitHub Actions CI behavior, and troubleshooting.
Mire jó az AI? Hát például arra, hogy ha írni szeretnék egy témáról, de lusta vagyok, az egyébként is Google segítsével összeszedett információkat rendszerbe szedni, akkor relatív gyorsan kézhez kapok egy bejegyzést.
A Page Object Model (POM) a szoftvertesztelés-automatizálás egyik legnépszerűbb és leghatékonyabb tervezési mintája (Design Pattern). A lényege, hogy az alkalmazás egyes weboldalait (vagy oldalrészeit) különálló objektumokként képezi le a kód szintjén.
Miért érdemes használni?
Karbantarthatóság: Ha megváltozik egy gomb ID-ja vagy egy mező elhelyezkedése, elegendő azt egyetlen helyen (a Page Object osztályban) átírni, a teszteseteket nem kell bántani.
Kód újrafelhasználhatósága: A gyakori műveletek (pl. bejelentkezés, keresés) egyszer vannak megírva, és bármelyik tesztből meghívhatók.
Olvashatóság: A tesztkód tiszta, átlátható és üzleti logikát követő lesz, rejtve a techniai megvalósítást (pl. DOM-lekérdezéseket).
Minta megvalósítás (Python + Selenium)
Az alábbiakban egy klasszikus bejelentkezési folyamat példáján keresztül látható a POM működése.
A Page Object osztály (login_page.py)
Ez az osztály tartalmazza az oldal elemeinek azonosítóit (lokátorait) és a végezhető műveleteket.
Python
from selenium.webdriver.common.by import ByclassLoginPage:def__init__(self,driver):self.driver = driver# Lokátorok (különválasztva a logikától)self._username_input =(By.ID,"username")self._password_input =(By.ID,"password")self._login_button =(By.CSS_SELECTOR,"button[type='submit']")self._error_message =(By.CLASS_NAME,"flash-error")# Akciók / Műveletekdefenter_username(self,username:str):self.driver.find_element(*self._username_input).send_keys(username)defenter_password(self,password:str):self.driver.find_element(*self._password_input).send_keys(password)defclick_login(self):self.driver.find_element(*self._login_button).click()# Összetett folyamat (Láncolt / Magasabb szintű akció)deflogin(self,username:str,password:str):self.enter_username(username)self.enter_password(password)self.click_login()defget_error_message(self)->str:returnself.driver.find_element(*self._error_message).text
A Teszteset (test_login.py)
A tesztkód csak a Page Object által nyújtott metódusokat használja, így végtelenül egyszerű és olvasható.
Ne tegyél assertion-öket a Page Object-be: A assert kifejezések a tesztfájlban maradjanak, a Page Object csak adatot adjon vissza vagy állapotot módosítson.
Page Factory használata: Bizonyos keretrendszerekben (pl. Java + Selenium) a @FindBy annotációkkal még tisztább szerkezet érhető el.
Lazy loading: Az elemeket csak akkor kérd le a DOM-ból, amikor ténylegesen szükség van rájuk (például dinamikus felületek esetén).
A Page Object Model (POM) megvalósítása a modernebb eszközökkel (mint a Playwright vagy a Selenium Java-alapú változata) még letisztultabbá válik, mivel ezek a keretrendszerek beépített architektúrával támogatják a megbízhatóbb elemkezelést.
Az alábbiakban mindkét megközelítésre találsz egy-egy komplett kódmintát.
Playwright + TypeScript (Ajánlott / Modern megközelítés)
A Playwright eleve magában foglalja az automatikus várakozást (Auto-waiting), így nincs szükség explicit wait-ek kézi kezelésére.
A Page Object osztály (pages/LoginPage.ts)
TypeScript
import {Page,Locator} from '@playwright/test';exportclassLoginPage{readonlypage:Page;readonlyusernameInput:Locator;readonlypasswordInput:Locator;readonlyloginButton:Locator;readonlyerrorMessage:Locator;constructor(page:Page){self.page=page;// A Playwright-ban a lokátorok deklaratívak, nem kérdezik le azonnal a DOM-otthis.usernameInput=page.locator('#username');this.passwordInput=page.locator('#password');this.loginButton=page.locator('button[type="submit"]');this.errorMessage=page.locator('.flash-error');}asyncgoto(){awaitthis.page.goto('https://example.com/login');}asynclogin(username:string,password:string){awaitthis.usernameInput.fill(username);awaitthis.passwordInput.fill(password);awaitthis.loginButton.click();}asyncgetErrorMessage():Promise<string>{returnawaitthis.errorMessage.textContent() ||'';}}
A Tesztfájl (tests/login.spec.ts)
TypeScript
import {test,expect} from '@playwright/test';import {LoginPage} from '../pages/LoginPage';test.describe('Bejelentkezés tesztek',()=>{letloginPage:LoginPage;test.beforeEach(async({page})=>{loginPage=newLoginPage(page);awaitloginPage.goto();});test('Sikeres bejelentkezés',async({page})=>{awaitloginPage.login('valid_user','correct_password');// Ellenőrzés Playwright assert-telawaitexpect(page).toHaveURL('https://example.com/dashboard');});test('Hibás bejelentkezés',async()=>{awaitloginPage.login('invalid_user','wrong_password');awaitexpect(loginPage.errorMessage).toBeVisible();awaitexpect(loginPage.errorMessage).toContainText('Érvénytelen adatok');});});
Java + Selenium (Klasszikus keretrendszer)
Java környezetben a PageFactory és a @FindBy annotációk használata a legelterjedtebb POM minta.
A @FindBy elemek lekezeléséhez várakozás (WebDriverWait) kellhet
Párhuzamosítás
Alapból támogatott a tesztfutztatóban
TestNG vagy JUnit szálkezelést igényel
Inicializálás
Egyszerű objektumkonstruktor
PageFactory.initElements() hívás szükséges
A Playwright Custom Fixture funkciója segítségével a Page Object osztályok példányosítását teljesen kiszervezheted a tesztekből. Ezzel elkerülhető, hogy minden egyes tesztfájlban manuálisan kelljen megadni a const loginPage = new LoginPage(page) sorokat.
A tesztek így közvetlenül paraméterként kérhetik el a szükséges oldalobjektumokat, az infrastruktúra pedig automatikusan példányosítja és előkészíti azokat.
A Page Object osztályok (pages/)
A megszokott módon hozzuk létre az oldalklasszokat.
TypeScript
// pages/LoginPage.tsimport {Page,Locator} from '@playwright/test';exportclassLoginPage{readonlypage:Page;readonlyusernameInput:Locator;constructor(page:Page){this.page=page;this.usernameInput=page.locator('#username');}asyncgoto(){awaitthis.page.goto('/login');}}// pages/DashboardPage.tsimport {Page,Locator} from '@playwright/test';exportclassDashboardPage{readonlypage:Page;readonlyuserMenu:Locator;constructor(page:Page){this.page=page;this.userMenu=page.locator('#user-menu');}}
A Custom Fixture létrehozása (fixtures/baseTest.ts)
Itt terjesztjük ki a Playwright alapértelmezett test objektumát, megadva a saját Page Object fixture-jeinket.
TypeScript
import {test as base} from '@playwright/test';import {LoginPage} from '../pages/LoginPage';import {DashboardPage} from '../pages/DashboardPage';// 1. Típusdefiníció a fixture-ökhöztypeMyFixtures={loginPage:LoginPage;dashboardPage:DashboardPage;};// 2. A 'base.extend' használatával regisztráljuk a saját fixture-jeinketexportconsttest=base.extend<MyFixtures>({// Automatikusan példányosítja a LoginPage-t és igény esetén megnyitja az oldaltloginPage:async({page},use)=>{constloginPage=newLoginPage(page);awaitloginPage.goto();// Akár előkészítő lépéseket is tehetünk ideawaituse(loginPage);// Átadja az objektumot a tesztnek},// Példányosítja a DashboardPage-tdashboardPage:async({page},use)=>{constdashboardPage=newDashboardPage(page);awaituse(dashboardPage);},});// Az 'expect'-et is exportáljuk a kényelmes importálásértexport {expect} from '@playwright/test';
A Fixture-ök használata a tesztekben (tests/login.spec.ts)
A @playwright/test helyett a saját fixtures/baseTest fájlunkból importáljuk a test objektumot. A tesztfüggvény paramétereként megadott nevek alapján a Playwright automatikusan beadagolja a megfelelő példányokat.
TypeScript
// Figyelem: A saját kiterjesztett test objektumunkat importáljuk!import {test,expect} from '../fixtures/baseTest';test('Sikeres bejelentkezés custom fixture-rel',async({loginPage,dashboardPage})=>{// A loginPage.goto() már lefutott a fixture-ben!awaitloginPage.usernameInput.fill('standard_user');// A dashboardPage is azonnal használható, nem kellett 'new'-val példányosítaniawaitexpect(dashboardPage.userMenu).toBeVisible();});
Miért ez a legnépszerűbb Playwright architektúra?
Nulla boilerplate kód: Nem kell beforeEach blokkokban példányosítani az osztályokat.
Lazy loading (Lusta betöltés): Csak azok a Page Object-ek példányosulnak, amiket a teszt fejlécében ({ loginPage, dashboardPage }) kifejezetten elkérsz.
Beépített tear-down: A fixture-ben a use() hívás utáni kódrészlet automatikusan lefut a teszt végén (takarításra, kijelentkezésre ideális).
Ma ilyen AI-s napom van. Egyre jobban tör be a mindennapi munkámba, és úgy tűnik, hogy a hétvégeimet is ez teszi ki. Miért? Kérdezheted joggal. Megmondom. Az IT-ban, de gyanítom a többi szakmában is jobb, ha értünk hozzá, és megtanuljuk rutinosan használni, mintsem lemaradjunk róla, és nézzük bambán, ahogy az élet felsuhan előttünk.
Nézzük, mire is mentem elsőre.
Az alábbi PowerShell-script végigpásztázza a megadott mappát (és annak almappáit), a fájlok SHA256 hash értéke alapján azonosítja a duplikációkat, majd az eredményt kiírja a képernyőre és elmenti egy CSV-fájlba.
PowerShell duplikáció-kereső script
Hozz létre egy find-duplicates.ps1 fájlt, és másold bele az alábbi kódot:
PowerShell
# --- BEÁLLÍTÁSOK ---$TargetFolder="C:\Elérési\Út\A\Mappához"# Cseréld ki a vizsgálandó mappa útvonalára$OutputFile="C:\Elérési\Út\duplikatumok.csv"# Ide menti az eredménytWrite-Host"Fájlok indexelése és hash értékek számítása..."-ForegroundColor Cyan# 1. Összes fájl lekérése és méret szerinti csoportosítása (gyorsítási lépés)$fileGroups=Get-ChildItem-Path $TargetFolder-Recurse -File -ErrorAction SilentlyContinue |Group-Group-Object -Property Length |Where-Object{$_.Count-gt1}$duplicates=@()$totalGroups=$fileGroups.Count$counter=0# 2. Csak az azonos méretű fájlok SHA256 hash-ének ellenőrzéseforeach($groupin$fileGroups){$counter++Write-Progress-Activity "Duplikátumok keresése"-Status "Fájlcsoportok feldolgozása: $counter / $totalGroups"-PercentComplete (($counter/$totalGroups)*100)$hashTable=$group.Group|Get-FileHash-Algorithm SHA256 |Group-Object-Property Hash |Where-Object{$_.Count-gt1}foreach($hashGroupin$hashTable){foreach($filein$hashGroup.Group){$duplicates+=[PSCustomObject]@{Hash=$hashGroup.NamePath=$file.PathSizeMB=[math]::Round((Get-Item$file.Path).Length /1MB,2)}}}}# 3. Eredmények megjelenítése és mentéseif($duplicates.Count-gt0){Write-Host"`nTalált duplikátumok:"-ForegroundColor Green$duplicates|Format-Table-AutoSize -Property Hash, SizeMB, Path$duplicates|Export-Csv-Path $OutputFile-NoTypeInformation -Encoding UTF8Write-Host"Az eredmények elmentve ide: $OutputFile"-ForegroundColor Yellow}else{Write-Host"`nNem találhatók duplikált fájlok."-ForegroundColor Green}
Így használd:
Nyisd meg a PowerShell-t (akár Rendszergazdaként, ha védett mappákat is vizsgálsz).
Írd át a $TargetFolder változót a keresni kívánt mappára.
Futtasd a scriptet:PowerShell.\find-duplicates.ps1
Megjegyzés: Ha a PowerShell letiltja a scriptek futtatását, futtasd ezt a parancsot a munkamenetben:
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
Majd második próbálkozásra
Módosítottam a scriptet, hogy a célmappát (és opcióként a kimeneti CSV-fájl helyét is) paraméterként fogadja el.
A módosított script kódja:
PowerShell
<#.SYNOPSIS Fájl duplikációkat kereső és gyűjtő PowerShell script..DESCRIPTION A script végigpásztázza a paraméterként megadott mappát (és annak almappáit), és az SHA256 hash értékek alapján azonosítja a duplikátumokat. Az eredményt megjeleníti a konzolon és CSV-fájlba menti..PARAMETERTargetFolder A vizsgálandó mappa útvonala (kötelező paraméter)..PARAMETEROutputFile A kimeneti CSV fájl útvonala (opcionális, alapértelmezett: .\duplikatumok.csv).#>[CmdletBinding()]param([Parameter(Mandatory=$true,Position=0,HelpMessage="Kérjük, adja meg a vizsgálandó mappa útvonalát!")][ValidateScript({Test-Path$_-PathType Container })][string]$TargetFolder,[Parameter(Mandatory=$false,Position=1)][string]$OutputFile=".\duplikatumok.csv")# Abszolút útvonalak feloldása$TargetFolder=(Resolve-Path$TargetFolder).Path$OutputFile=$ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath($OutputFile)Write-Host"Mappa elemzése: $TargetFolder"-ForegroundColor CyanWrite-Host"Fájlok indexelése és méret szerinti csoportosítása..."-ForegroundColor Cyan# 1. Összes fájl lekérése és méret szerinti csoportosítása (gyorsítási lépés)$fileGroups=Get-ChildItem-Path $TargetFolder-Recurse -File -ErrorAction SilentlyContinue |Group-Object-Property Length |Where-Object{$_.Count-gt1}$duplicates=@()$totalGroups=$fileGroups.Count$counter=0if($totalGroups-eq0){Write-Host"`nNem találhatók azonos méretű fájlok, nincsenek duplikátumok."-ForegroundColor Greenexit}# 2. Csak az azonos méretű fájlok SHA256 hash-ének ellenőrzéseforeach($groupin$fileGroups){$counter++Write-Progress-Activity "Duplikátumok keresése"-Status "Fájlcsoportok feldolgozása: $counter / $totalGroups"-PercentComplete (($counter/$totalGroups)*100)$hashTable=$group.Group|Get-FileHash-Algorithm SHA256 |Group-Object-Property Hash |Where-Object{$_.Count-gt1}foreach($hashGroupin$hashTable){foreach($filein$hashGroup.Group){$duplicates+=[PSCustomObject]@{Hash=$hashGroup.NamePath=$file.PathSizeMB=[math]::Round((Get-Item$file.Path).Length /1MB,2)}}}}# 3. Eredmények megjelenítése és mentéseif($duplicates.Count-gt0){Write-Host"`nTalált duplikátumok:"-ForegroundColor Green$duplicates|Format-Table-AutoSize -Property Hash, SizeMB, Path$duplicates|Export-Csv-Path $OutputFile-NoTypeInformation -Encoding UTF8Write-Host"Az eredmények elmentve ide: $OutputFile"-ForegroundColor Yellow}else{Write-Host"`nNem találhatók duplikált fájlok."-ForegroundColor Green}
Használati példák:
Alapértelmezett használat (a mappa elérést megadva, az eredmény a beállítások szerint a duplikatumok.csv-be kerül):PowerShell.\find-duplicates.ps1 -TargetFolder "C:\Users\Public\Documents"
Pozicionális paraméterként (nem kell kiírni a névadó kapcsolót):PowerShell.\find-duplicates.ps1 "D:\Képek"
Egyedi CSV kimeneti fájlnév megadásával:PowerShell.\find-duplicates.ps1 -TargetFolder "D:\Dokumentumok" -OutputFile "C:\Riportok\doksi_duplikatumok.csv"
Újdonságok a scriptben:
Automatikus mappa-ellenőrzés (ValidateScript): Ha nem létező vagy hibás mappa-útvonalat adsz meg, a script még a futás előtt jelez és leáll.
Mappa-kötelezőség (Mandatory = $true): Ha paraméter nélkül indítod el a scriptet, a PowerShell automatikusan megkérdezi tőled a célmappa útvonalát.
Nem vagyok teljes mértékben elragadtatva az eredménytől, de mára ez bőven elég volt, majd folytatjuk…
A Playwright 1.63 frissítése megérkezett, és számtalan olyan funkciót hoz, amelyek lényegesen egyszerűbbé teszik a komplex tesztelési munkafolyamatokat, a párhuzamosítást és a hibakeresést.
Az alábbiakban összefoglaltuk a kiadás legfontosabb újdonságait és fejlesztéseit.
Key Features & Újdonságok
1. Test Locks (Tesztreteszek)
Megoldást nyújt a közös erőforrások (pl. központi adatbázis, globális fiókbeállítások vagy külső API-k) használata miatti ütközésekre.
Lehetővé teszi zárolások (locks) megadását, így a tesztek automatikusan sorba állnak a kritikus erőforrások eléréséhez, elkerülve a párhuzamos futtatásból eredő hibákat.
2. Step paraméterek és feliratok (test.step)
A test.step() mostantól elfogad egy params opciót, amellyel saját metaadatokat és paramétereket adhatsz át a lépésekhez.
A riportokban és a Trace Viewerben tisztábban nyomon követhetők az egyedi lépésekhez tartozó változók és hívási argumentumok.
3. Aria Traces & Bővített Tracing
A Trace Viewer új aria pillanatképeket (snapshots) támogat.
Megkönnyíti a hozzáférhetőségi (accessibility) elemek és az ARIA fa állapotának elemzését hibakeresés közben.
4. Új Scroll Opciók az akcióknál
A legtöbb akciónál (pl. .click()) megjelent egy új scroll opció ("auto" | "none").
Lehetőséget biztosít arra, hogy kikapcsold a Playwright automatikus „scroll-into-view” viselkedését, ha egy elem pozícióját manuálisan szeretnéd kezelni.
5. Új teszt opciók és CLI parancsok
Nagyobb hozzáférhetőség tesztelése: Új reducedMotion, forcedColors és contrast opciók a testOptions alatt.
--add-reporter parancssori opció: Bővítheted a meglévő riporterek listáját ahelyett, hogy felülírnád a playwright.config.ts-ben megadottakat.
omitTags opció: Letisztultabb tesztcímek a riportokban (suppress-eli az automatikusan hozzáfűzött tegeket a list, line, dot, github és junit riportereknél).
Eltávolított (Deprecated) API-k
A 1.63-as verzió végleg kivezeti a régen elavultnak jelölt funkciókat:
Locator.ariaRef() (használd helyette a locator.ariaSnapshot() funkciót).
handle opció a BrowserContext.exposeBinding és Page.exposeBinding esetében.
logger opció a BrowserType.connect és connectOverCDP metódusoknál.
videosPath és videoSize konfig opciók (használd a recordVideo-t).
Frissítés
A legújabb verzióra való átálláshoz futtasd a projekt gyökerében az alábbi parancsot:
A Playwright 1.63-ban megjelent Test Locks (Tesztreteszek) opció segítségével megakadályozhatod, hogy bizonyos tesztek egyszerre futjanak és ütközzenek a közös erőforrásokon (pl. ugyanazon tesztfiók beállításai, adatbázis vagy külső API-k), miközben a többi független teszt továbbra is párhuzamosan fut.
Az alábbiakban bemutatjuk a legfontosabb használati módokat kódpéldákkal.
1. Egyedi teszt zárolása egy megnevezett retesszel (lock)
Ha van két vagy több teszted, amelyek ugyanazt a megosztott erőforrást módosítják, megadhatsz nekik egy azonos lock nevet az opciók között:
TypeScript
import {test,expect} from '@playwright/test';// Ez a teszt lefoglalja az 'admin-account' reteszttest('Adminisztrátor frissíti a cég nevét',{ lock:'admin-account'},async({page})=>{awaitpage.goto('https://example.com/admin/settings');awaitpage.getByLabel('Cégnév').fill('Új Cégnév Kft.');awaitpage.getByRole('button',{ name:'Mentés'}).click();awaitexpect(page.getByText('Sikeres mentés')).toBeVisible();});// Ez a teszt megvárja, amíg az előző teszt elengedi az 'admin-account' reteszttest('Adminisztrátor módosítja az időzónát',{ lock:'admin-account'},async({page})=>{awaitpage.goto('https://example.com/admin/settings');awaitpage.getByLabel('Időzóna').selectOption('Europe/Budapest');awaitpage.getByRole('button',{ name:'Mentés'}).click();awaitexpect(page.getByText('Sikeres mentés')).toBeVisible();});
Hogyan működik? Amíg a Worker 1 az első tesztet futtatja az admin-account retesszel, addig a Worker 2 nem kezdi el a második tesztet. A két teszt egymás után fog lefutni, de a csomag többi, független tesztje (pl. termékkeresés, kosárkezelés) továbbra is teljesen párhuzamosan fut a többi workeren.
2. Egész tesztcsoport zárolása (test.describe)
Ha egy egész blokknyi teszt egyetlen közös erőforráson dolgozik, a lock opciót közvetlenül a test.describe() csoportra is ráteheted:
TypeScript
import {test,expect} from '@playwright/test';test.describe('Adatbázis konfigurációs tesztek',{ lock:'database-config'},()=>{test('Alapértelmezett nyelv beállítása',async({page})=>{// ... teszt kód});test('Rendszerértesítések kikapcsolása',async({page})=>{// ... teszt kód});});
3. Több retesz egyidejű használata (Array)
Egy teszt akár több megosztott erőforrás zárolását is kérheti egyszerre. Ehhez adj meg egy tömböt a lock paraméterben:
TypeScript
import {test,expect} from '@playwright/test';test('Fizetési átjáró és szállítási beállítások egyidejű frissítése',{ lock: ['payment-sandbox','shipping-api'] },async({page})=>{// Ez a teszt csak akkor indul el, ha mindkét retesz szabadawaitpage.goto('https://example.com/admin/integrations');// ... teszt kód});
Néha hasznos tud lenni, ámbár nem gyakran fordul elő, hogy a semmiből kell építkezni, de akkor jól tud jönni, ha követünk egyfajta standardot. Talán azt mondanám, hogy a lokátorokat nem tenném külön, de van az a méretű projekt, ahol van ennek létjogosultsága.
Bár nagyon sokat használtam, mégsincs kéznél egy darab példakódom sem ezzel kapcsolatban. Így hát a Playwright bibliát fogom segítségül hozni a példák bemutatására.
Mire való?
Nekem ez akkor volt nagyon hasznos, amikor API teszteket írtam, és a GET endpoint válaszánál nem volt elég egy 200-as válaszkód, mivel a háttérben a szinkronizációs folyamat nem ért be, tehát a GET endpoint-ot addig kellett hívni, amíg a megfelelő válasz meg nem érkezett.
Elsőre én is, mint egy kis cserkész, betettem egy while loop-ba, és működött tökéletesen. Aztán rátaláltam a Playwright által támogatott gyári megoldásra, és azt kell mondanom, hogy zseniálisan jól működőtt.
awaitexpect.poll(async()=>{constresponse=awaitpage.request.get('https://api.example.com');returnresponse.status();},{// Custom expect message for reporting, optional. message:'make sure API eventually succeeds',// Poll for 10 seconds; defaults to 5 seconds. Pass 0 to disable timeout. timeout:10000,}).toBe(200);
Mi is történik itt? A GET endpoint válaszkódjával térünk vissza, és azt hasonlítjük össze az elvárttal. Teszük ezt addig, amíg tart a timeout-ban megadott érték.
Ekkor az intervals-ban megadott értékek fogják jelenteni a próbálkozások közt eltelt időt. Ezt érdemes úgy beállítani, hogy lehetőleg ne generáljuk túl nagy extra terhelést a rendszer számára.
Az expect.soft kapcsán nekem az a megélésem, hogy nagyon megoszlanak a vélemények. Vannak, akik teljes mértékben ellenzik a használatát, mások pedig – mint én is – úgy vannak vele, hogy vannak olyan esetek, amikor szükséges lehet. Ugye, soft esetén ha hibára fut, nem áll meg a futás, hanem megy tovább a teszt.