testover · start here

When the site breaks and nobody's looking, you still hear first

testover is an automated test suite for a Task Board web app. It runs by itself every Saturday and Sunday and posts ✅ pass or ❌ fail to your team chat, with nobody pressing a thing.

What it is

A sample web app (Task Board), 127 Playwright tests, and a runner plus notifier that works automatically on GitHub Actions.

What it does

Tests sign-up/login, task management, the profile page and the full user flow, then reports results to Discord or Slack.

The goal

Know right away whether the core features still work, without waiting for users to report it. It also serves as an end-to-end example for practicing QA automation.

The project in 6 steps

Follow along step by step to see what each part of the project is for and how the parts connect.

  1. The starting problem

    Nobody opens the site to check every week

    Basics like login or adding a task can break silently over a weekend, and you only find out when users complain. Checking by hand is slow and easy to forget.

    The fix: let a machine check on a schedule and report back in chat.
  2. What gets tested

    The Task Board app built into this project

    A user signs up or logs in → adds tasks with a priority → ticks them done, edits, deletes, searches and filters → updates their profile, changes the password, turns on dark mode, or deletes the account.

    Data lives in the browser's localStorage with no backend, so the app is easy to run and gives stable results.

    Files: app/index.html, app/server.mjs · demo user demo / demo1234
  3. The checker

    Playwright opens a real browser and uses the app like a person

    127 tests click buttons and fill forms, then check the result. They cover normal use, wrong or empty input, data after a reload, a phone-sized screen, and corrupted storage. Every test starts with a fresh browser, so nothing carries over between tests.

    See what's covered
    • login.spec: sign-up, login/logout, route guard, 404
    • tasks.spec: add/edit/delete/tick, search, filter
    • profile.spec: display name, password, dark mode, delete account
    • journey.spec: the full path from sign-up to account deletion, and two users whose data never mixes
    • contracts/ and characterization/: data-shape agreements and recorded behaviour (see test structure)
    • a11y.spec: accessibility scan with axe, WCAG 2.1 A/AA
    Files: tests/*.spec.ts, tests/support/pages.ts (Page Objects)
  4. You try it locally

    Run it in 3 commands

    You need Node.js 22 or newer. The app starts automatically. (On a new machine, first run git clone https://github.com/mongoemon/testover.git; the full steps are in README section 2.)

    npm ci
    npx playwright install chromium   # first time only
    npm test                          # run all 127 tests

    For a quick look use npm run test:smoke (the 5 core tests). To watch the browser work use npm run test:headed, then open the report with npm run report.

    You get: pass/fail per test, plus screenshots, video and a trace for any test that fails.
  5. It runs itself

    GitHub Actions runs every Saturday and Sunday

    The weekend-e2e.yml workflow starts every Saturday and Sunday at 09:00 Thailand time. It has a 20-minute timeout so a stuck job can't hang, and you can also run it by hand from the Actions tab whenever you want an extra check.

    Good to know: GitHub cron uses UTC and can start several minutes late.
  6. What lands in your inbox

    A summary message in Discord or Slack

    scripts/notify.mjs reads the test results and posts them to a webhook. On failure it names the failing tests and links to the run, where the full report is in Artifacts.

    ✅ PASS — weekend QA runpassed: 127 | failed: 0
    flaky: 0 | skipped: 0
    ❌ FAIL — weekend QA runpassed: 126 | failed: 1
    • Task board › deletes only the targeted task
    The end goal: open chat on a weekend morning, see ✅ and relax, or see ❌ and know exactly what to fix.

What the project can do

Numbers below are taken from the project README.

127

Test cases

E2E, contract, characterization and accessibility (plus 42 unit tests)

5

Smoke tests

A fast set for the main path: npm run test:smoke

10

Tags by test type

Run only @security, @validation and more with --grep

2

Notification channels

Discord and Slack share one webhook format, no code changes

Key files to know

If you want to change or add something, look here first.

File / folderRole
app/The Task Board app and a tiny static server, used as the test target
tests/All Playwright tests, split by area of the app
unit/Unit tests for the server and the notify script
scripts/notify.mjsReads test results and posts them to a webhook
.github/workflows/weekend-e2e.ymlThe schedule that runs everything automatically on GitHub
playwright.config.tsPlaywright settings (web server, reporters, retries)
Heads up: the app stores passwords as plain text in localStorage on purpose, so it can be tested without a backend. Never do this in a real product. Your webhook URL is a secret: keep it in GitHub Secrets only.

Where to go next