标签：#playwright

If you have ever tried building a website change detection system or visual testing tool, you’ve likely stumbled into the "False Positive Trap." You configure a cron job to monitor a target URL, take snapshots every 15 minutes, and compare them. But within hours, your inbox is flooded with alerts for: Tailwind CSS dynamic hash class mutations (e.g. class="bg-blue-500_a3f9" turning into class="bg-blue-500_b81c" after a deployment) Lazy-loaded images rendering at offset offsets Anti-bot verification scripts altering invisible DOM nodes Hydration mismatches in React/Vue single-page applications At PageWatch.tech , solving these exact edge cases was the primary focus of our engineering roadmap. In this article, I’ll share the 3 core algorithmic fixes we implemented to achieve reliable, noise-free website change monitoring. 🛑 Problem 1: Structural Hash Instability in Modern Frameworks Modern frontend frameworks like Next.js, Nuxt, and Remix insert dynamic build IDs, hydration keys, and inline CSS chunk hashes into the HTML structure. For example, a innocent paragraph tag might look like this today: <p class= "text-gray-700 css-1a2b3c" data-reactroot= "" > Product Price: $99 </p> And like this tomorrow after a routine production deployment: <p class= "text-gray-700 css-9x8y7z" data-reactroot= "" > Product Price: $99 </p> A standard raw string comparison flags this as a critical change even though zero user-facing content changed . The Solution: Attribute Normalization & CSS Class Sanitization Before computing DOM structural hashes, we run a normalize pass that strips generated hashes and framework-specific attributes: import * as htmlparser2 from " htmlparser2 " ; /** * Normalizes dynamic framework attributes and hashed CSS classes * before running DOM diff calculations. */ export function normalizeDOMNode ( node : any ): void { if ( node . attribs ) { // 1. Remove hydration and framework metadata const volatileAttrs = [ " data-reactroot " , " data-reactid " , " data-hydr

Most teams already keep Playwright or Robot Framework specs next to the product. Manual cases often live somewhere else — a spreadsheet, a cloud TMS, or a wiki page nobody updates after the first release. That is why automation coverage is usually a quarterly guess: the catalog and the specs never share an id. Put both in the same Git repo , give every manual case a stable id, and linking becomes a text match. Any IDE agent can do that if the cases are files it can already see — no custom AI product inside a test tool. One repo, two layers of the same suite Manual cases are YAML files under .gitoza-lite/test/cases/ (VS Code / Cursor extension) or .gitoza/test/cases/ (Desktop app). The filename without .yaml is the case id . Automated tests live wherever your team already puts them — tests/ , e2e/ , robot/ — in the same repository. Traceability is a shared id: put that case id on the automation side as a tag (or name), and on the YAML side as automated: true plus a params pointer. A PR can change the case, the Playwright spec, and the link in one review. Step 1 — Draft manual cases in the IDE Open the repo in Cursor or VS Code. Point the agent at a few existing case files so it learns your title style, tags, and step length. Then feed it a user story, a ticket, or a screenshot. Ask for several cases at once, not one shallow step. A useful prompt looks like: Read .gitoza-lite/test/cases/shopflow/auth/ for format. From ticket SHOP-184, draft three YAML cases (happy path, invalid password, locked account). Filename = case id. Use tags auth and smoke where it fits. Save the files under the suite folder. Then open the Gitoza Lite Test Repository tab to browse, edit, and — when you are ready — run them as a manual suite with Pass / Fail / Skip. The extension does not ship its own model. It keeps cases as plain YAML so whatever assistant you already use can read and write them. A minimal case: --- title : Login with valid credentials priority : high tags : [ smoke , auth ]

You have built an AI agent harness. It calls tools, routes requests, and returns results. Your team trusts its telemetry to tell you which tool was selected and why. That trust is a liability. An agent's own logs are self-reported. They tell you what the agent thinks it did, not what actually happened. A hallucinated tool name, a misrouted parameter, a silent fallback to a different function — none of these surface in the agent's own trace. You need an external witness. Here is how to build one. The Problem: Self-Reported Truth Is Not Truth Most teams validate agent behavior by reading the agent's own output. They check the tool_calls field in the response, match it against an expected schema, and call it done. This works until it doesn't. Consider a common failure mode: the agent decides to call search_knowledge_base but the LLM formats the tool name as searchKnowledgeBase . The routing layer silently normalizes it, the call succeeds, and the agent logs search_knowledge_base . Your test passes. The actual execution path was different from what you verified. Another pattern: the agent selects the correct tool but passes a parameter that the tool silently coerces. A date string gets parsed into a different timezone. A user ID gets truncated. The tool returns a result, the agent logs success, and your test never catches the drift. The root cause is the same. You are testing the agent's intent , not its execution . Intent is cheap to fake. Execution leaves fingerprints. The Solution: An External Observer You need a layer that sits between the agent and the tools it calls. This observer records every invocation — tool name, parameters, response, latency — without the agent knowing it is being watched. The observer does not trust the agent's logs. It trusts what it sees on the wire. Here is the architecture at a high level: Intercept every outbound call from the agent to a tool. Record the raw request before any normalization or routing. Compare the recorded call against

You have been here. The test suite is green. The deployment pipeline reports all checks passed. Then a customer opens a ticket with a screenshot that shows something your test never caught. The test passed in staging. It fails in production. And you cannot reproduce it locally. This is not a flaky test problem. It is a fidelity problem. Your test environment and your production environment are not the same thing. The gap between them is where real bugs live. Let me walk through one concrete example, the fix, and what it teaches about writing tests that survive the handoff to a real user. The Problem: Environment Drift A fintech team I worked with had a checkout flow. The test clicked "Pay Now", waited for a success message, and asserted the text "Payment successful" appeared on screen. It passed every time in staging. Customers reported that after paying, they saw a blank white page for several seconds before the success message appeared. Some of them closed the tab during that blank period, thinking the payment failed. The transaction went through. The customer never saw the confirmation. Support tickets piled up. The test never caught this because the staging environment served the success page in under 200 milliseconds. The blank period did not exist there. Production had a slower downstream service that introduced a three-second delay between the payment confirmation and the page render. The test was correct in what it checked. It was wrong in what it assumed about timing and state. The Fix: Test the Experience, Not Just the Outcome The fix was not to add a longer wait. The fix was to test what the user actually experiences during that gap. Here is a minimal Playwright test in TypeScript that catches this class of problem: import { test , expect } from ' @playwright/test ' ; test ( ' checkout shows loading state before success ' , async ({ page }) => { await page . goto ( ' /checkout ' ); await page . fill ( ' #card-number ' , ' 4111111111111111 ' ); await page

Gherkin is not a test automation tool. It never was. Yet here we are, five years into your SDET career, and you're staring at a feature file that reads like a step-by-step manual for a human tester. Given I log in with username "admin" and password "password123" . When I click the "Submit" button . Then I see the text "Welcome" on the screen . You've written two years of these. Your team calls it BDD. Your manager calls it "living documentation." And somewhere in the back of your mind, a quiet voice whispers: This is just a manual test case with extra steps. That voice is right. Let me say it plainly: if your Gherkin scenarios describe how the system works instead of what it should do, you are not doing BDD. You are writing manual test cases in a structured English format and calling it automation. The only thing you've automated is the illusion of progress. The problem isn't Gherkin. The problem is how we use it. Most teams adopt BDD because someone read a blog post about "collaboration" and "shared understanding." They install Cucumber or SpecFlow. They write feature files. They map steps to Selenium or Playwright code. And they call it a day. But look closely at what happens next. The product owner never reads the feature files. The developer skims them once and goes back to writing code. The QA engineer — that's you — becomes the sole maintainer of a growing pile of Gherkin that nobody else touches. You're not facilitating collaboration. You're translating manual test cases into a format that requires a compiler. Here's the real test. Take any feature file from your project. Hand it to a developer who has never seen it. Ask them to implement the feature using only the Gherkin as a spec. If they can write production code from it, you have real BDD. If they ask you for clarification, you have documentation theater. I've seen teams with hundreds of feature files. Beautifully formatted. Perfect indentation. Tags for every regression cycle. And not a single one of th

Most engineers expect AI-assisted automation to be the easy part. You describe a test, the model writes it, you move on. The first week will prove you wrong. Not because the code is bad. Because the code is almost right. And almost-right code is harder to debug than wrong code. Wrong code fails loudly. Almost-right code passes on Monday, fails on Tuesday, passes again on Wednesday, and by Thursday you are questioning whether you understand your own application. I have watched teams adopt AI copilots into their Playwright suites and spend the first five days doing nothing but untangling false passes. If you are about to start this journey, here is what that week actually looks like. The Problem: The Model Does Not Know What "Stable" Means A language model has never waited for a network response. It has never watched a flaky selector survive three CI runs and then collapse on the fourth. It writes tests from a static understanding of your page, not from the dynamic reality of your application. You will ask it to write a test that clicks a button and waits for a confirmation toast. The model will produce something like this: await page . click ( ' button:has-text("Submit") ' ); await page . waitForSelector ( ' .toast-success ' ); Looks fine. Runs fine. Then your team deploys a new build where the toast takes 400ms longer to appear because of an analytics call. The test fails. Not because the feature broke. Because the model assumed a timing that was never guaranteed. This is the core problem. The model writes tests that match the page as it was when the model saw it . It does not write tests that match the page as it will be . The Solution: Treat AI-Generated Tests as Drafts, Not Deliverables The shift is mental before it is technical. You cannot review AI-generated tests the way you review human-written tests. Human tests come with intent. AI tests come with patterns. You need a different review lens. First, look for every hardcoded wait. Replace it with a state-based

Frontend testing used to sound simple: open a page, find an element, click it, and verify the result. That description still works for basic workflows, but modern interfaces are no longer a single static DOM that changes in obvious ways. Components can render inside Shadow DOM. Modals can be portaled to a different part of the document. Server-rendered HTML can be replaced during hydration. Content can move because of CSS container queries. A page can look finished while several progressive-loading states are still changing underneath it. The hardest frontend bugs now tend to sit at the intersection of three things: State: what the application believes is happening. Timing: when the browser and framework apply changes. Geometry: where elements appear and whether users can actually interact with them. A stable test strategy has to observe all three. Shadow DOM and portals break naive assumptions about element location Component encapsulation is useful, but it changes how automation finds and interacts with elements. A control inside an open shadow root is not always reachable through the same selector strategy used for the main document. A portaled modal may appear visually next to a component while being rendered near the end of document.body . Focus can move into the modal even though the DOM hierarchy suggests that it belongs elsewhere. This guide to testing Shadow DOM and portaled modals without breaking browser automation suites covers the key challenges. The test should verify behavior, not merely the presence of a node: Can the user reach the control? Is the expected element visible above overlays? Does keyboard focus enter the modal? Is focus trapped correctly? Does Escape close it? Does focus return to the triggering element? Can a screen reader identify its label and role? Selectors still matter, but interaction boundaries matter more. A test that locates a button hidden behind another layer is not testing what the user experiences. Hydration creates a peri

A scraper fails, someone swaps the User-Agent, someone else adds a proxy, then the job starts passing locally but fails again in CI. That usually happens because Cloudflare did not block “scraping” as one thing. It evaluated several signals, and each failure needs a different fix. This is about authorized automation: your own sites, customer-approved workflows, testing, monitoring, data access you are allowed to perform. If you do not have permission to automate against a site, changing fingerprints or rotating IPs does not make it okay. Start with the failure you actually see Cloudflare failures often get collapsed into “403”, but the page body matters. Common cases: Error 1020 : usually an access denied page from a Cloudflare rule or bot score decision. The HTTP status may still be 403, so inspect the HTML. 403 without a 1020 page : often IP reputation, firewall rules, geo restrictions, or an auth problem. 429 : rate limit exhaustion. Slowing down can help here, but it will not fix a fingerprint problem. Endless Just a moment... page : your client did not complete the browser-side challenge. CAPTCHA or Turnstile loop : Cloudflare still considers the session borderline after earlier checks. Add classification before you add workarounds. Even a basic classifier saves time: import time import requests CLOUDFLARE_MARKERS = { " 1020 " : " cloudflare_access_denied " , " Just a moment " : " cloudflare_js_challenge " , " cf-turnstile " : " cloudflare_turnstile " , " cf-error-code " : " cloudflare_error_page " , } def classify_response ( resp : requests . Response ) -> str : body = resp . text [: 5000 ] if resp . status_code == 429 : return " rate_limited " for marker , label in CLOUDFLARE_MARKERS . items (): if marker in body : return label if resp . status_code == 403 : return " forbidden_unknown " return " ok " if resp . ok else f " http_ { resp . status_code } " def get_with_backoff ( url : str , max_attempts = 4 ): for attempt in range ( max_attempts ): resp = request

The issue was not the tools. It was opening five of them before deciding what the log file was for. The log file was already on the screen. A remote Windows workstation had failed a desktop build, and the relevant file was sitting in a local app directory, something like: C:\Users\<user>\AppData\Local\<app>\logs\build.log The remote session was working. The error was visible. The next step seemed small: get the log back to the local laptop, open it in a familiar editor, compare it with the issue notes, and pull out the part that mattered. That should have been a 30-second task. Instead, it turned into five context switches. The first context was the remote session The remote desktop session made sense. The build failed on that machine, the app was installed there, and the log path was easier to find visually than by guessing from memory. So far, nothing was wrong. The file was selected. The timestamp matched the failed run. The log looked useful. It probably had the stack trace, the missing dependency path, or the configuration mismatch that explained the build failure. Then came the small but surprisingly annoying question: How should this file leave the remote machine? That is where the workflow started to wobble. The second context was chat The first instinct in many teams is chat. Drop the file into a message to yourself, a teammate, or the debugging thread. It is fast, already open, and keeps the file near the conversation. For some files, that is the right move. A screenshot, a short error snippet, or a quick “does this look familiar?” artifact belongs naturally in the discussion. But a full log file is not always a chat artifact. If it goes into chat, will anyone know later whether it was the first failing run or the second? Will it be obvious which remote machine produced it? Will the file still be easy to find after the thread moves on? Chat was not wrong. It was just not clearly the right home for this specific file. So the workflow moved on. The third con

We’ve all been there. You get a notification from your smartwatch saying your heart rate has been a bit funky, or your blood oxygen is dipping. Usually, we ignore it until it becomes a problem. But what if your personal AI was looking out for you? 🤖 In this tutorial, we are building an Autonomous Health Agent . This isn't just a notification bot; it's a proactive system that uses Playwright browser automation , OpenAI Function Calling , and Python to monitor your health trends and—if things look suspicious for three days straight—literally opens a browser and books a doctor's appointment for you. By leveraging Autonomous AI Agents and Playwright automation , we are moving from "Passive Monitoring" to "Active Intervention." This is the future of Health Tech Automation . 🏗 The Architecture Before we dive into the code, let's look at how the data flows from a "scary heart rate" to a "confirmed appointment." graph TD A[Wearable Data/Health Logs] --> B{3-Day Anomaly Check} B -- Normal --> C[Stay Healthy! 🟢] B -- Abnormal --> D[Trigger AI Agent 🤖] D --> E[OpenAI Function Calling] E --> F[Playwright Browser Automation] F --> G[Hospital Booking Platform] G --> H[Appointment Confirmation 🏥] H --> I[Notify User via SMS/Email] 🛠 Prerequisites To follow along, you’ll need: Python 3.10+ Playwright : The king of modern browser automation. OpenAI API Key : For the "brain" of our agent. A healthy dose of curiosity! 🥑 pip install playwright openai pydantic playwright install chromium 👨‍💻 Step 1: Defining the "Brain" (OpenAI Function Calling) We don't want the LLM to just "talk" about booking an appointment; we want it to actually execute the action. We'll use OpenAI's Function Calling to bridge the gap between text and code. import json from openai import OpenAI client = OpenAI () # Define the tool our agent can use tools = [ { " type " : " function " , " function " : { " name " : " book_doctor_appointment " , " description " : " Books a medical appointment based on department and s

Most guides to OTP testing in Playwright include a function that looks something like this: function extractOtp ( emailBody : string ): string { const patterns = [ / \b(\d{6})\b / , /code [ : \s] + (\d{4,8}) /i , /verification [ : \s] + (\d{4,8}) /i , /OTP [ : \s] + (\d{4,8}) /i , ]; for ( const pattern of patterns ) { const match = emailBody . match ( pattern ); if ( match ) return match [ 1 ]; } throw new Error ( ' OTP not found in email body ' ); } This function is fragile. It breaks when the email template changes. It returns false positives when the email body contains order IDs or timestamps. It requires you to maintain regex patterns for every email provider your app might use. There is a better way. The Problem with Regex OTP Extraction When your app sends a verification email, the OTP is buried somewhere in the HTML body. To extract it you need to: Fetch the raw email body Parse HTML or plain text Apply regex patterns that match your specific email format Handle edge cases — 4-digit vs 6-digit codes, codes in tables, codes in buttons Every time your email provider changes their template, your regex breaks. Every time you add a new auth provider, you write new patterns. It is maintenance overhead that compounds forever. The right place to extract the OTP is at the infrastructure layer — before the email even reaches your test suite. How ZeroDrop Extracts OTPs at the Edge ZeroDrop catches emails at Cloudflare's edge before storing them. When an email arrives, the worker runs OTP detection on the body and stores the result as a structured field alongside the raw email. By the time your test calls waitForLatest() , the OTP is already extracted and sitting in email.otp . No regex. No HTML parsing. No maintenance. const email = await mail . waitForLatest ( inbox ); email . otp // "847291" — already extracted Setup npm install zerodrop-client No API key. No signup. No environment variables. Basic OTP Test import { test , expect } from ' @playwright/test ' ; import

Browser automation with Playwright, Python, GitHub Actions, and Entire to auto-enter San Francisco Stern Grove concert lotteries each week!

You built a LangFlow prototype. Every test passed. You exported the flow, dropped it into n8n, and the first production run broke. This is not a bug report. It is a pattern. The three-year SDET who has built LangFlow prototypes but hit mysterious failures when deploying the same logic in n8n production already knows the feeling. The prototype felt solid. The production pipeline felt like a different language. It is not. The difference is execution context. LangFlow runs in a notebook-like environment where state is forgiving and retries are invisible. n8n runs in a workflow engine where every node is a transaction boundary and every failure is final unless you explicitly handle it. Here are the three tests that pass in LangFlow but fail in n8n production, and what they teach about building reliable AI pipelines. Test 1: The "LLM Returns Valid JSON" Test What passes in LangFlow: You send a prompt asking the model to return JSON. The response comes back as a string. You parse it with json.loads() . It works. You move on. What fails in n8n: The model returns a string that starts with a code block. Or a trailing comma. Or a markdown fence. Or a preamble sentence before the JSON. Or nothing at all because the context window was exceeded. Why the difference: LangFlow's Python node silently tolerates malformed output. If json.loads() fails, you see the error in the output panel and fix the prompt. n8n's JSON node does not retry. It does not fall back. It throws a structured error that stops the entire workflow. The fix is not a better prompt. The fix is a validation layer that normalizes LLM output before parsing. import json import re def extract_json ( raw : str ) -> dict : # Strip markdown fences cleaned = re . sub ( r ' ^``` (?:json)?\s* ' , '' , raw . strip ()) cleaned = re . sub ( r ' \s* ```$ ' , '' , cleaned ) # Find the first { and last } start = cleaned . find ( ' { ' ) end = cleaned . rfind ( ' } ' ) if start == - 1 or end == - 1 : raise ValueError ( " No JSON o

The Playwright Playbook — Part 7: The CI/CD Setup Nobody Shows You "A test suite that only runs on your laptop isn't a test suite. It's a hobby." Six parts in, we have a serious framework. POM-based UI tests. Network interception. Multi-user contexts. A full API testing layer. Visual regression across four viewports. A complete debugging toolkit. Now it needs to run automatically. On every pull request. On every merge. On every deployment. Without you touching it. Most CI/CD tutorials for Playwright show you this: # The "tutorial" version everyone copies - run : npx playwright test That's not a CI setup. That's a shell command in a YAML file. A real production CI/CD pipeline for Playwright has: Sharding — split tests across multiple machines and finish in a fraction of the time Browser matrix — Chromium, Firefox, WebKit in parallel Docker — identical environment on every machine, every time Artifacts — HTML report, traces, screenshots, videos — downloadable from every run Failure notifications — your team knows within seconds, not the next morning Separate VRT workflow — visual regression on its own cadence, not blocking every PR Environment-specific pipelines — staging vs production, different configurations Let's build all of it. 🎯 🏗️ Where We Left Off After Part 6, our full project structure is: playwright-playbook/ ├── tests/ │ ├── auth/login.spec.ts ✅ Part 1 │ ├── tasks/task-management.spec.ts ✅ Part 1 │ ├── network/ ✅ Part 2 │ ├── multi-user/ ✅ Part 3 │ ├── multi-tab/ ✅ Part 3 │ ├── api/ ✅ Part 4 │ ├── visual/ ✅ Part 5 │ └── debug/trace-examples.spec.ts ✅ Part 6 ├── pages/ │ ├── LoginPage.ts ✅ Part 1 │ ├── TaskPage.ts ✅ Part 1 │ └── DashboardPage.ts ✅ Part 3 ├── api/ │ ├── TaskApiClient.ts ✅ Part 4 │ └── AuthApiClient.ts ✅ Part 4 ├── fixtures/ │ ├── auth.fixture.ts ✅ Part 1 │ ├── tasks.json ✅ Part 2 │ ├── empty-tasks.json ✅ Part 2 │ ├── tasks-har.har ✅ Part 2 │ ├── multi-user.fixture.ts ✅ Part 3 │ └── api.fixture.ts ✅ Part 4 ├── scripts/ │ └── record-har.ts ✅

You have ISTQB Foundation. ISTQB Advanced. Certified ScrumMaster. A cloud cert. A security testing cert. Maybe a Python for Testers badge from a platform. And you still cannot write a test that finds a real bug. I interviewed someone like you last quarter. The resume was a wall of acronyms. The conversation was a wall of theory. "I follow the V-model." "I use equivalence partitioning." "I believe in shift-left." Then I asked: "Show me one test you wrote that caught something the developer missed." Silence. Not because they were nervous. Because they had never written a test that found a bug. They had written tests that passed. They had written tests that covered requirements. They had never written a test that broke something. That is the difference between a certification holder and a tester. Certifications test your memory. Bugs test your thinking. Let me show you what I mean. The Certification Trap Certifications are not useless. They give you vocabulary. They give you structure. They give you something to put on LinkedIn so recruiters stop asking if you know what a test case is. But they do not teach you how to find bugs. Here is why. Every certification exam tests known knowledge. You study a syllabus. You memorize definitions. You answer multiple-choice questions about boundary value analysis. You pass. Then you sit in front of an application. The application does not have a syllabus. It does not have a boundary value analysis section in the documentation. It has a login form that sometimes lets you in with a password that is clearly wrong, but only on Tuesdays, and only if the server clock is behind by exactly four minutes. No certification prepares you for that. The tester with 10 certifications treats testing like a checklist. They write test cases from requirements. They execute them. They mark pass or fail. They report coverage metrics. The tester who finds bugs treats testing like an investigation. They start with a hypothesis. They try to prove the appl

The Playwright Playbook — Part 3: Multi-User, Multi-Tab & Browser Context Testing "Most frameworks test one user at a time. Real apps don't work that way." In Part 1, we built the full foundation — POM, storageState , fixtures, and a clean project structure. In Part 2, we took control of the network layer — mocking APIs, simulating failures, and asserting on real network calls. Now we tackle the scenario that breaks most automation frameworks. Multiple users. Simultaneously. In one test. Think about your app for a moment. How many features actually involve just one user? Admin assigns a task → regular user sees it appear in real time User A edits a record → User B gets a notification Admin revokes access → User's session should invalidate Two users try to edit the same record → conflict resolution kicks in These are real features. They need to be tested. And page.goto('/login') in a beforeEach won't get you there. Playwright's browser context architecture was built exactly for this. Let's use it properly. 🎯 🏗️ Where We Left Off After Part 2, our project looks like this: playwright-playbook/ ├── tests/ │ ├── auth/ │ │ └── login.spec.ts ✅ Part 1 │ ├── tasks/ │ │ └── task-management.spec.ts ✅ Part 1 │ └── network/ ✅ Part 2 │ ├── api-mocking.spec.ts │ ├── error-simulation.spec.ts │ └── network-assertions.spec.ts ├── pages/ │ ├── LoginPage.ts ✅ Part 1 │ └── TaskPage.ts ✅ Part 1 ├── fixtures/ │ ├── auth.fixture.ts ✅ Part 1 │ ├── tasks.json ✅ Part 2 │ ├── empty-tasks.json ✅ Part 2 │ └── tasks-har.har ✅ Part 2 ├── scripts/ │ └── record-har.ts ✅ Part 2 ├── .auth/ │ ├── admin.json │ └── user.json ├── global-setup.ts ✅ Part 1 ├── playwright.config.ts ✅ Part 1 └── .env By the end of Part 3, we add: playwright-playbook/ ├── tests/ │ ├── multi-user/ ← NEW │ │ ├── role-permissions.spec.ts │ │ └── realtime-collaboration.spec.ts │ └── multi-tab/ ← NEW │ └── multi-tab-flows.spec.ts ├── pages/ │ └── DashboardPage.ts ← NEW ├── fixtures/ │ └── multi-user.fixture.ts ← NEW Every one of th

You’ve built something with Playwright. It works perfectly in your local environment. CI is green....

Every developer who has written a Playwright test for OTP verification has written this line: const otp = email . body . match ( / \b\d{6}\b / )?.[ 0 ]; It works. Until it doesn't. The email body changes format. The OTP appears inside an HTML table. The sending service wraps it in a <span> . Your regex matches a phone number instead of the code. The test fails intermittently and you spend an hour debugging something that has nothing to do with the feature you're testing. The regex problem OTP extraction via regex is brittle by nature. You're pattern-matching against a string that your email sending service controls — not you. Any time the template changes, your tests break. Here's what a typical OTP test looks like today: import { test , expect } from ' @playwright/test ' ; import { ZeroDrop } from ' zerodrop-client ' ; const mail = new ZeroDrop (); test ( ' user can verify OTP ' , async ({ page }) => { const inbox = mail . generateInbox (); // 1. Trigger OTP send await page . goto ( ' /login ' ); await page . fill ( ' [data-testid="email"] ' , inbox ); await page . click ( ' [data-testid="submit"] ' ); // 2. Wait for email const email = await mail . waitForLatest ( inbox , { timeout : 15000 }); // 3. Extract OTP — the fragile part const otp = email . body . match ( / \b\d{6}\b / )?.[ 0 ]; if ( ! otp ) throw new Error ( ' OTP not found in email body ' ); // 4. Enter OTP await page . fill ( ' [data-testid="otp"] ' , otp ); await page . click ( ' [data-testid="verify"] ' ); await expect ( page ). toHaveURL ( ' /dashboard ' ); }); The test works — but line 14 is carrying all the risk. Change the email template and the test breaks. Add a phone number to the footer and the regex matches the wrong number. Send a 4-digit OTP instead of 6 and you need to update the pattern. OTP extraction at the edge ZeroDrop extracts OTPs before they reach your test. The Cloudflare Worker that catches incoming emails runs a pattern match on the plain-text body and stores the result alongsi

Overview Today's focus was on automating article publishing to CSDN and WeChat MP (微信公众号) using Playwright, after CSDN deprecated its public Open API. Key achievements include: injecting Markdown content into CSDN's dynamic editor, handling title input quirks, implementing QR code login for WeChat MP, updating the Dev.to API publisher, and consolidating platform configs into a single YAML file. We also fixed session log capture after a Claude Code update changed the log file path. Problems and Solutions 1. CSDN Open API Deprecation → Browser Automation Background : In early 2026, CSDN silently shut down its public Open API. All endpoints returned 404/403. We needed a fallback to keep publishing to China's largest developer platform. Solution : Use Playwright to simulate a real user login and article creation. The approach: Launch a headless Chromium browser. Navigate to CSDN's login page. Perform one-time manual login via QR code. Serialize cookies to csdn_cookies.json . On subsequent runs, load the cookies and skip login. Go to the editor, inject Markdown content via DOM manipulation, fill the title, and click publish. Code snippet : import asyncio from playwright.async_api import async_playwright async def publish_to_csdn ( title : str , content_md : str ): async with async_playwright () as p : browser = await p . chromium . launch ( headless = True ) context = await browser . new_context ( storage_state = " csdn_cookies.json " if exists else None ) page = await context . new_page () await page . goto ( " https://mp.csdn.net/mp_blog/creation/editor " ) # Inject content await page . evaluate ( f ''' () => {{ const editor = document.querySelector( ' .editor-content ' ); if (editor) {{ editor.innerHTML = ` { escaped_content } `; editor.dispatchEvent(new Event( ' input ' , {{ bubbles: true }})); }} }} ''' ) # Fill title await page . fill ( ' #title-input ' , title ) await page . click ( ' button:has-text( " 发布 " ) ' ) await page . wait_for_url ( " **/mp_blog/manage/ar

Most testing tutorials ignore e-learning completely. Here's how to build a Playwright test suite that validates your SCORM packages actually work across LMS platforms. Why E-Learning Testing Is Different If you've ever published a SCORM package to an LMS and watched it silently fail — no completion recorded, quiz scores vanishing, navigation broken — you know the pain. E-learning content doesn't behave like a typical web app. It runs inside an LMS-provided iframe, communicates through a JavaScript API (the SCORM Runtime), and its behavior changes depending on which LMS hosts it. Manual QA across even 3-4 LMS platforms is slow and error-prone. In this tutorial, I'll walk you through setting up Playwright to automate SCORM package testing — from basic content loading to verifying API calls and completion status. Prerequisites Before we start, make sure you have: Node.js 18+ installed Playwright ( npm init playwright@latest ) A SCORM 1.2 or 2004 package (a .zip file containing your e-learning content) A local LMS for testing — we'll use SCORM Cloud (free tier) or a simple SCORM API shim Step 1: Set Up a Local SCORM Runtime Shim Testing SCORM content requires an API that mimics what an LMS provides. Rather than spinning up a full Moodle instance, we'll create a lightweight shim. Create a file called scorm-api-shim.js : // scorm-api-shim.js // Mimics the SCORM 1.2 Runtime API that an LMS would expose window . API = { _data : {}, _initialized : false , _calls : [], LMSInitialize : function ( param ) { this . _initialized = true ; this . _calls . push ({ method : ' LMSInitialize ' , param , timestamp : Date . now () }); console . log ( ' [SCORM] LMSInitialize called ' ); return " true " ; }, LMSGetValue : function ( key ) { this . _calls . push ({ method : ' LMSGetValue ' , key , timestamp : Date . now () }); return this . _data [ key ] || "" ; }, LMSSetValue : function ( key , value ) { this . _data [ key ] = value ; this . _calls . push ({ method : ' LMSSetValue ' , key