Playwright Automation Testing Project for Freshers: 10 Test Cases and CI

Updated: 16 October 2026. Want a QA Automation Engineer or Software Test Engineer role but have only college projects? Build one small, reliable test portfolio instead of listing tools you have never used. This guide outlines a Playwright automation testing project for freshers with JavaScript, 10 example test cases, a runnable test for a public demo page, bug-report guidance, a GitHub Actions workflow and resume bullet points. Use a demo app you own or are authorized to test; avoid sending repeated automated requests to unrelated production websites.

What should your Playwright testing portfolio demonstrate?

Choose a suitable demo application

Use a small locally running ecommerce demo or a web app you built for your portfolio, with search, cart and login. Avoid real payment details and never embed passwords or tokens in GitHub. For the introductory runnable test below, the Playwright documentation website is used only to demonstrate navigation and assertions; adapt the actual portfolio tests to an application under your control.

Install Playwright Test with JavaScript

Install a current supported Node.js version first, then run the official setup command in your project directory:

npm init playwright@latest
npx playwright test
npx playwright show-report

When prompted, choose JavaScript if you prefer it over TypeScript. The setup normally creates a Playwright configuration and example test. Browser binaries may need to be installed on your machine; follow the instructions printed by the installer. See official installation instructions for up-to-date prerequisites.

A complete first Playwright test

Save this example as tests/docs.spec.js. It visits a public documentation page and checks the page title and navigation link; it is not a test of a shopping cart.

const { test, expect } = require('@playwright/test');

test('Playwright docs navigation works', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);

  await page.getByRole('link', { name: 'Get started' }).click();
  await expect(
    page.getByRole('heading', { name: 'Installation' })
  ).toBeVisible();
});

Use getByRole and visible labels when possible rather than brittle positional selectors. Playwright’s web-first assertions automatically retry while waiting for the expected UI state, which is more robust than arbitrarily sleeping for several seconds. Details are in the Playwright writing-tests guide.

10 automation test cases for your own demo shop

These are illustrative test cases and expected outcomes, not ten tests already implemented or executed. Implement and verify them against the behavior of your chosen demo application.

Example test for your locally running application

The snippet below assumes your app is running at http://localhost:3000 and has an accessible button named Add to cart and a cart-count test ID. Adapt these locators to your actual HTML and start the application server before running the test.

const { test, expect } = require('@playwright/test');

test('cart count increases after adding an item', async ({ page }) => {
  await page.goto('http://localhost:3000');
  await page.getByRole('button', { name: 'Add to cart' }).first().click();
  await expect(page.getByTestId('cart-count')).toHaveText('1');
});

Make your test suite more reliable

• Independent tests: reset state so one test does not depend on the previous test’s cart or login.
• Stable locators: prefer roles, labels and intentional test IDs over generated CSS class names.
• No manual sleeps: rely on Playwright assertions and condition-based waiting where appropriate.
• Real assertions: a click without a meaningful expected result is not a useful test.
• Safe secrets: use CI secrets or a local environment file that is excluded from Git.
• Failure evidence: enable traces and review artifacts when a test fails.

Use GitHub Actions to run tests

Playwright’s installer can generate a CI workflow automatically. If you make a minimal workflow yourself for a repository with a committed package-lock.json, use a configuration like this as a starting point. Your Node version, project build, demo server and any required environment variables must match your actual app.

name: Playwright Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

Important: a workflow for the localhost:3000 cart test also needs to build and start the demo application, or configure Playwright’s webServer; otherwise that test will fail in CI. The standalone documentation-site test does not require a local app. To inspect recorded errors and screenshots, use Playwright’s CI guide and Trace Viewer documentation. Uploaded traces may contain sensitive data, so restrict artifact visibility where necessary.

Example bug report for your portfolio

Seven-day implementation checklist

1. Day 1: select or build a demo app and write a one-page test plan.
2. Day 2: initialize Playwright and implement navigation and search tests.
3. Day 3: add cart tests with clear expected outcomes.
4. Day 4: test form validation and deliberately invalid login cases.
5. Day 5: isolate test data and remove flaky locators or sleeps.
6. Day 6: configure CI, collect reports and write one real issue record.
7. Day 7: document architecture, run instructions, limitations and improvements in GitHub.

Resume project description example

UI Automation Testing Portfolio | Playwright, JavaScript, GitHub Actions: Designed and automated functional test scenarios for a self-built ecommerce demo; used accessible locators and assertions, configured CI test runs and documented reproducible defects. Include only the features you actually completed and can demonstrate.

Frequently asked questions

Can a fresher learn Playwright without Selenium?

Yes. Basic HTML, JavaScript, HTTP and test-case design are useful foundations. Knowing Selenium is not a prerequisite for Playwright, although the job description may require a specific tool.

Does Playwright replace manual testing?

No. Exploratory testing, usability judgment, test planning and risk analysis remain valuable. Automate repeatable scenarios where the cost and reliability make sense.

How many tests are enough for a fresher project?

A handful of stable, well-reasoned tests with clear documentation can be more impressive than a large suite of copied, failing test cases.

Should screenshots and traces be public?

Only when they contain no sensitive data. Logs and traces can expose application data and authentication information.

Related Hiring365 resources

Continue with our Java Spring Boot portfolio project, SQL practice questions, GitHub portfolio guide, and job-description checklist.

References: Playwright installation; writing tests; CI setup. Inspected 16 October 2026. Original examples are independent Hiring365 educational exercises, not an employer assignment.

Yash Borekar

Yash Borekar is a Programmer Analyst Trainee at Cognizant and the founder of Hiring365. With a background in Computer Engineering, he shares researched job opportunities, technical resources, and practical career guidance to help freshers and early-career professionals.

Hiring365 is independently operated and is not affiliated with Cognizant.

See author's posts