Een aparte browser is geen apart account
Browsercontexten scheiden cookies, niet gedeelde servergegevens. Geef parallelle tests die gegevens wijzigen aparte accounts en data.

Vertaalde editie. Technische identificatiegegevens blijven in hun oorspronkelijke vorm.
Twee voorbeeldtests lopen tegelijk. De eerste verwacht tijdzone UTC. De tweede slaat "Europe/Riga" op. Beide hebben een nieuwe browsercontext, maar gebruiken hetzelfde account. De eerste faalt omdat de servergegevens veranderden, ondanks de gescheiden cookies.
Dit onderscheid is van belang wanneer een agent meer dekking genereert dan uw oude suite had. Parallelle uitvoering kan aannames over gedeelde toestanden blootleggen die verborgen bleven toen tests achter elkaar werden uitgevoerd. Het praktische artefact is een eigendomskaart: welke test mag schrijven welk account en welk record, en wanneer die status wordt gereset.
Teken de twee grenzen afzonderlijk
De authenticatiegids van Playwright legt browsercontextisolatie en het laden van de geverifieerde status uit. Het waarschuwt ook dat tests die de status aan de serverzijde wijzigen, verschillende accounts moeten gebruiken wanneer gelijktijdig gebruik een andere test zou beïnvloeden. Een context is een cliëntgrens. Een account-, tenant- of recordnaamruimte is een applicatiegrens. Geen van beide is een vervanging voor de ander.
Vermeld beide in beoordeling. Een gegenereerde test moet de context identificeren die hij gebruikt en de gegevens die hij kan wijzigen. Als het alleen onveranderlijke inhoud leest, kan het delen van een account redelijk zijn. Als er instellingen worden gewijzigd, bestellingen worden gemaakt of een gedeeld document wordt bewerkt, controleer dan het account- en recordeigendom voordat er meer parallelle werknemers worden toegevoegd.
Kies de kleinste bruikbare eigendomseenheid
De Playwright-handleiding documenteert één account per parallelle werker voor tests die de status aan de serverzijde wijzigen. Dat kan de interferentie tussen werknemers verminderen. Het betekent niet dat elke test binnen een werknemer willekeurige veranderingen achter zich kan laten. Reset of see de status die elke test nodig heeft, en maak het opschonen expliciet.
Soms is de veiligere eenheid een uniek record per test in plaats van een account per test. Voor een takenlijst die eigendom is van een team, kunnen afzonderlijke accounts nog steeds dezelfde gedeelde lijst schrijven. Voor een afrekenproces kan een unieke winkelwagen- of bestelnaamruimte nodig zijn. Kies de eenheid uit de daadwerkelijke regels voor delen van het product, niet uit de naam van de browser-API.
Een datacontract dat een agent kan volgen
Schrijf vier velden naast elk scenario: naamruimte van de eigenaar, installatiestatus, toegestane schrijfbewerkingen en opruimgedrag. Een illustratief contract kan een staging-gebruiker voor één werknemer reserveren, een leeg karretje vóór de test plaatsen, toestaan dat alleen synthetische orders worden gemaakt, en deze orders verwijderen nadat het bewijs van de mislukking is bewaard. Geef aan wat er gebeurt als het opruimen mislukt; anders erft de volgende run een mysterie.
Houd de installatie onafhankelijk van het succes van een andere test. Playwrightarmaturen bieden een gestructureerde levenscyclus voor het voorbereiden en vrijgeven van testbronnen. Gebruik die levenscyclus om eigendom leesbaar te maken, en niet om een globaal gedeeld account achter een handige armatuurnaam te verbergen. De recensent moet kunnen achterhalen wie de eigenaar is van elke veranderlijke hulpbron.
Een QA-team kan deze kaart gebruiken om minder tijd te besteden aan het opsporen van accidentele kruistestfouten. Een team zonder QA kan beginnen met één kritieke stroom en één begrensde staging-accountpool. Geen van beide hoeft een enorme omgeving te bouwen voordat wordt gemeten of de eerste stroom nuttig is.
De authenticatiestatus is een geheimhoudend bestand
Playwright waarschuwt dat de opgeslagen browserstatus cookies en headers kan bevatten die een account kunnen nabootsen. De gids ontmoedigt het vastleggen van deze bestanden in repository's, inclusief privérepository's. Behandel ze als inloggegevens: houd ze uit de bronarchieven, beperk de toegang en genereer ze indien nodig opnieuw.
Geef een verkenningsagent nooit een productiesessie alleen maar omdat het instellen van het inloggen ongemakkelijk voelt. Gebruik staging-accounts met de machtigingen die nodig zijn voor het scenario. Een aparte browser met een beheerderscookie is nog steeds een beheerder.
Tel valse mislukkingen als echt werk
Houd fouten bij die worden veroorzaakt door een gedeelde status, afzonderlijk van productregressies. Neem de minuten op die zijn besteed aan het opnieuw inzaaien van accounts en het onderzoeken van interferentie in de reparatiekosten van een automatiseringspiloot. Meer gegenereerde tests kunnen de dekking vergroten, maar ze kunnen ook de twist vergroten als het eigendom onduidelijk is. De besparing ontstaat wanneer nuttige dekking en voorspelbare gegevens het herhalingswerk verminderen, en niet wanneer alleen al het aantal tests toeneemt.
Veelgestelde vragen
Isoleert een nieuwe browsercontext servergegevens?
Nee. Het scheidt de browserstatus aan de clientzijde, maar twee geverifieerde contexten kunnen nog steeds hetzelfde account- of serverrecord wijzigen.
Moet elke test een ander account gebruiken?
Niet noodzakelijkerwijs. Toneelschrijver documenteert gedeelde accounts voor tests die geen interferentie veroorzaken, en één account per parallelle werker voor schrijvers van serverstatussen. Gedeelde productrecords moeten mogelijk verder worden gescheiden.
Kan ik een geverifieerde opslagstatus vastleggen?
Playwright waarschuwt dat het cookies en headers kan bevatten die een account kunnen nabootsen, en raadt af om deze zelfs in privéopslagplaatsen te plaatsen.