Creating a Fully Running Test Automation Framework in Under 3 Minutes with Cursor

In this tutorial, you’ll generate a clean, production-ready web UI automation framework in under 3 minutes using Cursor—and you’ll validate a real-world scenario: a failed login on SauceDemo for a locked-out user.

I’ll also embed my screen recording in the post so you can follow the exact flow I used end-to-end.

---

What you’ll build

A working Gradle project using:

• Java 17
• JUnit 5
• Selenide
• Gradle (Groovy DSL)

With best-practice structure:

• Page Object Model (POM)
• Clear separation:
• test logic
• page interactions
• configuration
• External configuration:
• base URL
• credentials
• A real test:
• open https://www.saucedemo.com
• login as locked_out_user
• Verify the error message:

Epic sadface: Sorry, this user has been locked out.

---

 

---

Step 1: Create an empty folder + open it in Cursor

1. Create a new folder, e.g. saucedemo-selenide-junit5

2. Open it in Cursor

3. Make sure Cursor can create files in the project (normal default)

That’s all—no manual Gradle init needed if you’re letting Cursor generate everything.

---

Step 2: Paste this prompt into Cursor

This is the exact prompt the framework is based on (copy/paste as-is):

You are a Senior QA Automation Engineer.

Create a clean, production-ready web UI test automation framework using:

- Java 17

- JUnit 5

- Selenide

- Gradle (Groovy DSL)



Architecture & Best Practices:

- Follow Page Object Model (POM).

Separate:

- Test logic

- Page interactions

- Configuration



Use Selenide best practices:

- No explicit waits

- Centralized browser configuration

- Stable, readable locators

- Configuration must be externalized (URL, credentials).

- Code must be readable, maintainable, and scalable.



Project Structure:

src

└── test

    ├── java

    │   ├── base

    │   │   └── BaseTest.java

    │   ├── config

    │   │   └── TestConfig.java

    │   ├── pages

    │   │   └── LoginPage.java

    │   └── tests

    │       └── LoginTest.java

    └── resources

        └── application.properties



Functional Requirements:

1. Open https://www.saucedemo.com

2. Try to login using:

Username: locked_out_user

Password: secret_sauce

3. Verify that login fails with error message 

"Epic sadface: Sorry, this user has been locked out."



What to Generate:

- build.gradle with all required dependencies

- Browser and timeout configuration

- Base test setup using JUnit 5 lifecycle hooks

- LoginPage Page Object with actions and assertions

- LoginTest using JUnit 5 and Selenide assertions

- application.properties for configuration



Execution:

The project must be runnable with:

./gradlew test



Generate complete, runnable code for all files.

Why this prompt works

It forces Cursor to:

• generate all files, not fragments
• follow a known structure
• implement a real assertion
• externalize config (so you don’t hardcode URLs and creds into tests)

---

Step 3: Make sure Cursor generates these files

After Cursor responds, your repository should include at least:

• build.gradle
• src/test/java/base/BaseTest.java
• src/test/java/config/TestConfig.java
• src/test/java/pages/LoginPage.java
• src/test/java/tests/LoginTest.java
• src/test/resources/application.properties

If you’re missing any of these, ask Cursor:

“Create the missing files and ensure the project runs with ./gradlew test.”

---

Step 4: What the code should do (high-level)

TestConfig.java

Central place to configure Selenide:

• base URL
• browser (optional)
• timeout
• screenshot / reports folder (optional)

BaseTest.java

JUnit 5 lifecycle hooks:

• set up config once (or before each test)
• optionally clean browser state

LoginPage.java (Page Object)

Encapsulates:

• locators (username, password, login button, error message)
• actions (open page, login)
• assertions (error visible + exact text)

LoginTest.java

Reads like a scenario:

• open login page
• attempt login as locked out user
• assert correct error is shown

---

Step 5: Run it

From the project root:

./gradlew test

You should see:

• Gradle downloads dependencies
• Selenide launches a browser
• test runs
• test passes ✅ (because the expected error is displayed)

---

Expected behavior on SauceDemo

The locked_out_user is a known user on SauceDemo that always fails login with the message:

Epic sadface: Sorry, this user has been locked out.

Your test should assert the exact message, not something vague—this is important for stable UI test feedback.

---

Final Thoughts

What you’ve seen here isn’t magic — it’s leverage.

Cursor didn’t “replace” test automation skills. It amplified them.
The reason this worked in under 3 minutes is because the intent, structure, and expectations were clear from the start.

The real takeaway is this:

• If you know what good architecture looks like
• If you can describe clean separation of concerns
• If you understand how tests should read and behave

…then tools like Cursor become a serious productivity multiplier rather than a code generator you have to babysit.

This small example already gives you:

• a maintainable project structure
• a real negative test with a meaningful assertion
• a foundation you can safely extend in a real project

From here, scaling is easy:

• add more page objects
• add reporting
• add CI
• add parallelism

The hardest part — getting started correctly — is already done.

If this tutorial helped you, try repeating the exercise with:

• a positive login flow
• a different browser
• a new assertion
• or an entirely different application

You’ll quickly notice that the speed gain compounds.

The future of test automation isn’t writing less code — it’s spending less time on the wrong code.

The Pillars of Leadership

 💡 Leadership in IT: It Starts With You

Leadership isn’t about titles or control — it’s about authenticity, growth, empathy, and self-awareness.

👤 Authenticity

People spot fake. They notice when you say one thing and do another.

If you call your team a “family” but threaten disciplinary action the next day, you lose trust instantly.

Be real, be consistent — your words and actions must align.

🌱 Growth

Leadership means helping others grow, not cloning yourself.

If a junior delivers good work that’s not exactly how you’d do it, praise them. Then guide them.

Confidence builds competence — not constant correction.

🤝 Empathy & Flexibility

No two people are the same. Great leaders see individuals, not headcount.

Your job is to mix strengths and balance weaknesses.

A team of only “rockstars” or only juniors fails — just like you can’t build a house with only hammers.

🧭 Self-Leadership

You can’t lead others if you can’t lead yourself.

Know your triggers, manage your emotions, own your weaknesses.

If you don’t, your team will pay the price for what you haven’t yet learned to control.

In the end, leadership is not about power — it’s about trust, growth, and balance.

API E2E Tests – Your Application’s Real-time X-Ray

 🚀 What if API tests could do more than check small pieces of your system?

For years we’ve treated API automation as “low-level only” — tiny isolated checks that live far away from the real user experience.

But here’s the thing:

You can mirror your entire E2E user flow through APIs… and the value is enormous.

🔗 E2E API = Your Backend Mirror of the UI Flow

Map the exact journey the user takes in the frontend, directly through the backend.

No browsers. No selectors. No flakiness.

Just real business logic, executed fast.

It’s like having an x-ray of your product’s most important flows.

🛡️ A stronger safety net

UI E2E tests catch issues last.

API E2E tests catch them early.

Together:

UI → validates the experience

API → validates the system

A double layer of confidence.

🎯 Instant FE vs. BE debugging

If the UI flow fails but the API E2E flow passes → Frontend issue

If both fail → Backend or integration issue

No more “whose bug is it?” meetings.

🔍 Clarity for everyone

E2E API flows make hidden logic visible.

Engineers, QA, PMs, even non-technical stakeholders can understand what’s happening under the hood.

It’s transparent. It’s traceable. And it’s fast.

💡 Final Thought

E2E API testing doesn’t replace traditional API checks — it completes them.

It sits perfectly between low-level tests and fragile UI automation.

Sometimes the smartest innovation is simply using what we already have… better.

Test Automation – Value Over Perfection

 🛑 Stop trying to build the perfect test automation framework.

Because by the time you finish, your product will have already changed.

🚀 Test Automation: Progress Over Perfection

One of the biggest traps teams fall into when building a test automation framework is trying to make it perfect from day one. But here’s the truth:

Frameworks evolve together with the product. You can’t design one that lasts forever.

Here are the principles I’ve learned over the years:

✅ Focus where it matters

Start with the major user flows. No one will thank you for automating error messages if critical bugs slip into production.

✅ Keep it simple (KISS)

Don’t over-engineer. A framework that’s hard to maintain or confusing for new joiners adds no value.

✅ Think about your team

If your QAs can code, use the language most widespread in the team.

If not, go pragmatic: Postman for APIs, record & play for UI.

The best framework is the one your team can actually use.

✅ Test what’s relevant

Focus on common browsers, devices, and OS versions. Don’t waste weeks covering edge cases like IE8 on Windows XP.

✅ Pick the right level

- Unit tests for isolated checks

- API tests for speed and reliability

- UI tests only for key end-to-end flows

✅ Start now, improve later

Even an “imperfect” suite that saves you 2 hours of daily manual testing gives you back 40 hours a month. That’s time you can reinvest in improving your framework and skills.

⚖️ Test automation is not about elegance or perfection — it’s about value. Start simple, adapt to your team, and iterate. Progress always beats paralysis.

Test Management Without Bureaucracy

 🧭 Test Management: Transparency Without Bureaucracy

The goal of test management isn’t paperwork — it’s transparency.

A good process should make the QA effort visible, showcase product quality at any moment, and help the team share knowledge efficiently.

But when it turns into bureaucracy, it fails its purpose.

🎯 The Real Value of Test Management

Done right, test management helps the team:

• See where quality stands — instantly.

• Understand testing progress and risk.

• Reuse knowledge and learn from the past.

It’s about visibility and collaboration, not about filling out endless fields or updating spreadsheets.

⚙️ Keep It Lean

• Don’t overdo documentation. You don’t need a test case for every ticket. Thousands of unmaintained tests become noise.

• Pick the right tool. Integrate QA into the same system developers use. Avoid silos.

• Automate updates. Connect your pipelines and test suites so reporting happens automatically.

🚀 The Outcome

When test management is lightweight, integrated, and automated, it enables:

• Faster, more confident releases

• Clear insight into product quality

• A shared understanding of risk and coverage

If it feels like bureaucracy, simplify it.

Because the real job of test management isn’t to manage tests — it’s to enable quality at speed.