DEV Community: muhammad Sanaev

Why QA Engineers Should Learn Playwright MCP

muhammad Sanaev — Mon, 25 May 2026 18:21:01 +0000

How I used Cursor, Playwright MCP, and Playwright CLI to build real automation for SwiftCart

AI will not magically turn weak tests into strong automation. But it can help QA engineers move faster when it is used the right way.

Recently, I built a small automation project for a SwiftCart e-commerce app using Playwright, TypeScript, Cursor, Playwright MCP, Context7 MCP, and GitHub Actions CI.

The biggest lesson was simple:

Playwright MCP does not replace Playwright. It helps you inspect the app faster so you can create better Playwright tests.

That difference matters.

What is Playwright

Playwright MCP lets Cursor interact with the browser through tools like:

browser_navigate
browser_click
browser_type
browser_snapshot
browser_wait_for

Regular Playwright runs your test files:

npx playwright test

Playwright MCP helps during development. It lets Cursor open the app, inspect flows, understand locators, and help generate test code.

Simple way to remember it:

Playwright MCP = helps inspect and build tests
Playwright CLI = runs the final tests

The website itself is not using MCP. Cursor is using MCP to inspect the website.

Why QA engineers should care

A big part of automation is not just writing code. It is deciding:

What flow should be tested?
Which locator is stable?
What should be asserted?
Is this a real bug or a weak test?
Can this test run in CI?

MCP helps with the discovery part. It can inspect the app and help generate a first version faster.

But the QA engineer still has to review, clean, refactor, and validate the test.

AI can speed up the work. It should not replace judgment.

What I automated in SwiftCart

I tested three common e-commerce flows:

Search flow

Homepage → Search input → Results page → Product results visible

Add to cart flow

Products page → Product detail → Add to cart → Cart page → Item visible

Checkout and login validation

Cart → Checkout → Login required → Checkout page → Form validation

These are realistic flows that QA teams often automate in e-commerce applications.

My Workflow

The workflow was:

1. Use Playwright MCP to inspect the app
2. Discover user flows and locators
3. Generate initial Playwright tests
4. Run tests with Playwright CLI
5. Fix failures
6. Refactor into Page Object Model
7. Add test.step() for better reporting
8. Add GitHub Actions CI
9. Extend into API testing

The key point: I did not treat AI output as final code. I used it as a starting point, then cleaned it into a maintainable automation framework.

Api Testing Extension

After the UI tests, I also created an API testing repo using Playwright request API.

UI test:

Open browser → click buttons → check page behavior
API test:

Send request directly to backend → check status code and JSON response
For SwiftCart, I tested endpoints like:

GET /products
GET /products/{id}

The API tests checked:

status code is 200
response is JSON
products exist
product fields exist
invalid product IDs return 404

API tests are much faster because they do not open a browser.

Context7 MCP: Real-Time Library Docs for Your AI Coding Assistant (And Why Your QA Workflow Needs It)

muhammad Sanaev — Sat, 23 May 2026 21:08:46 +0000

The problem

While working on my Swiftcart QA automation project, I asked my AI agent a simple question:

“What’s your knowledge cutoff date?”

It answered: April 2024.

That matters because Playwright changes fast. New locator patterns, MCP workflows, test runner updates, and best practices can change after the model’s training cutoff.

What Context7 MCP is

Context7 - Up-to-date documentation for LLMs and AI code editors

Pull up-to-date, version-specific documentation and code examples for any library directly into Cursor, Claude Code, Windsurf, and other AI coding tools.

context7.com

Context7 MCP is a documentation server for AI coding assistants.

Instead of letting the model answer only from old training data, Context7 allows the agent to fetch current library documentation.

For my workflow, I used it with:

Cursor
Playwright
Context7 MCP
Playwright MCP
Swiftcart demo app

Why this matters for QA automation

AI can generate tests quickly, but it may also:

suggest outdated syntax
hallucinate APIs
create brittle locators
miss current Playwright best practices
generate tests that pass but don’t test the right thing

Context7 does not replace knowing Playwright. It gives the AI better context.

How I connected Context7 MCP

In my project, I created:

.vscode/mcp.json

{
  "servers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Confirmation
After restarting Cursor, I asked the agent:

Use Context7 MCP specifically.
Do not use web search.
Resolve the Playwright library ID, then fetch locator docs.
List the exact Context7 tool names used.

A good sign is seeing tools like:

context7: resolve-library-id
context7: query-docs

Swiftcart app
↓
Playwright MCP inspects the real page
↓
Context7 MCP provides current Playwright docs
↓
Cursor generates the first test draft
↓
I review locators and assertions
↓
Final tests run with Playwright CLI

The REST Assured Setup Nobody Shows You: Handling Auth Tokens That Expire Mid-Suite

muhammad Sanaev — Thu, 23 Apr 2026 06:27:07 +0000

Most REST Assured tutorials show you a single given().when().then() against a sample API and call it done. That's fine for learning the syntax, but it doesn't cover what you actually need on a real project things like config per environment, clean test structure, and handling auth tokens that expire while the suite is running.

I'm Mukhammadjon Sanaev, a QA Automation Engineer in San Francisco. I've worked across e-commerce, logistics, and sports tech. This post walks through a simple REST Assured + TestNG + Maven setup I'd use on day one of a new API testing project, plus one problem I ran into on a real checkout API that isn't in the tutorials.

What We're Building

A small Java project that:

Uses REST Assured for API calls
Uses TestNG as the test runner
Runs against dev or staging with a single command
Handles an auth token that expires mid-run

Examples are based on an e-commerce checkout API — the kind of thing you'd test at a Shopify- or Wayfair-style company. Nothing proprietary, just the shape of a real checkout flow.

Project Structure
Keep it simple on day one:

api-tests/
├── pom.xml
├── testng.xml
└── src/test/
    ├── java/com/example/tests/
    │   ├── BaseTest.java
    │   ├── TokenManager.java
    │   └── CheckoutTests.java
    └── resources/
        └── config.properties

Step 1: pom.xml

xml<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>api-tests</artifactId>
    <version>1.0</version>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>rest-assured</artifactId>
            <version>5.4.0</version>
        </dependency>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.10.2</version>
        </dependency>
    </dependencies>
</project>

Step 2: Config File
Under src/test/resources/config.properties:
properties

base.url=https://api-dev.example.com
auth.url=https://auth-dev.example.com/oauth/token
client.id=your-client-id
client.secret=your-client-secret

Tip: don't commit real secrets to git. In a real project, read client.secret from an environment variable instead.

Step 3: BaseTest
Sets the base URL for every test:

javapublic class BaseTest {
    @BeforeSuite
    public void setup() {
        RestAssured.baseURI = "https://api-dev.example.com";
    }
}

Step 4: The Auth Problem
Here's the naive way to handle auth, which most tutorials show:
java// Fetch the token once, reuse forever

String token = given()
    .auth().basic("client", "secret")
    .post("/auth/token")
    .jsonPath().getString("access_token");

This works for 10 tests. It breaks when your suite gets bigger.
The Problem
On one project, our API tokens expired after 15 minutes. Our regression suite took about 22 minutes to run. The first batch of tests passed fine, then around test 140 everything started failing with 401 Unauthorized — not because the code was wrong, but because the token had expired halfway through the run.
The fix isn't to make the suite shorter. The fix is making the framework aware that tokens expire.
The Fix: A Simple TokenManager

java

public class TokenManager {
    private static String token;
    private static Instant expiresAt;

    public static String getToken() {
        if (token == null || Instant.now().isAfter(expiresAt)) {
            refresh();
        }
        return token;
    }

    private static void refresh() {
        Response response = given()
            .formParam("grant_type", "client_credentials")
            .formParam("client_id", "your-client-id")
            .formParam("client_secret", "your-client-secret")
            .post("https://auth-dev.example.com/oauth/token");

        token = response.jsonPath().getString("access_token");
        int expiresIn = response.jsonPath().getInt("expires_in");
        // Refresh 60 seconds early to avoid edge cases
        expiresAt = Instant.now().plusSeconds(expiresIn - 60);
    }
}

Two things worth noting:

The 60-second buffer. If you refresh exactly when the token expires, you can still hit a race condition with the server clock. Refreshing a bit early avoids that.
It only refreshes when needed. Most tests just grab the cached token.

Using It
Every API call pulls a fresh token through TokenManager:
javapublic class CheckoutTests extends BaseTest {

    @Test
    public void getCart_returnsItems() {
        given()
            .header("Authorization", "Bearer " + TokenManager.getToken())
            .pathParam("cartId", "cart-123")
        .when()
            .get("/cart/{cartId}")
        .then()
            .statusCode(200)
            .body("items", hasSize(greaterThan(0)));
    }
}

Step 5: Running It
testng.xml:

xml

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="API Tests">
    <test name="Checkout">
        <classes>
            <class name="com.example.tests.CheckoutTests"/>
        </classes>
    </test>
</suite>

Run:
bash

mvn test

That's it a working API test suite that doesn't fall over when tokens expire.
What I'd Add Next
This is a starting point, not the finished framework. Once the basics work, I'd add:

Separate config files for dev, staging, and prod
JSON schema validation on responses
An HTML report like Allure or Extent Reports
CI/CD integration with Jenkins or GitHub Actions

The Takeaway
The tricky parts of API automation aren't the tools REST Assured, TestNG, and Maven are straightforward once you've set them up once. The tricky parts are the problems that only show up when a real suite runs against a real API: auth tokens expiring, environment config drift, response schemas changing silently.
If you're setting this up for the first time, start small. Get one test running, handle auth properly, then grow from there.