eduTrain

Lesson 15 / الدرس 15

Running without you / الإجراء من غيرك

A test suite that only runs when someone remembers is barely a suite. Continuous integration is a machine that runs it on every change, and the value is entirely in how fast it tells somebody, and whether they believe it.

مجموعة اختبارات لا تجري إلا حين يتذكر أحد بالكاد تكون مجموعة. والتكامل المستمر آلة تجريها عند كل تغيير، وقيمتها كلها في سرعة إخبارها أحدًا، وفي هل يصدّقونها.

Continuous integration is a server that watches the repository and, whenever anyone pushes, checks out the code, installs what it needs, starts the application and runs your tests. Nothing about it is conceptually clever — it is the same commands you run locally, on a machine that never forgets and never decides it is probably fine.

What changes when a machine runs it

  • No browser window. Tests run headless, so anything that depended on you watching — a manual login, a file you had open — fails.
  • A clean machine, every time. No cached login, no leftover test data, no browser extension. This is a feature: it is the only environment that resembles a new user.
  • Different speed. Usually slower and more variable, which is where every fixed waitForTimeout you wrote comes back to find you.
  • Nobody is watching. The output is all anyone will see, so the screenshot, video and trace the runner saves are the whole of your evidence. 
# .github/workflows/test.yml — the whole idea, in one file
name: tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npm run test

      # Without this, a failure in CI is a sentence with no evidence behind it.
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/
The last block is the one people leave out and then regret. A red build with no screenshot, video or trace forces whoever investigates to reproduce it blind — and that is usually the moment someone decides the suite is more trouble than it is worth.

Fast enough to be read

A suite that takes forty minutes gets ignored, because nobody waits forty minutes to know whether their change was fine. Split it: the fast, broad checks — units, API tests, a handful of smoke journeys — on every push, and the long browser suite nightly or before a release. Feedback that arrives after the developer has moved on is feedback that costs more than it saves.

Check yourself / اختبر نفسك

1. Why upload screenshots and traces only on failure?

2. A full browser suite takes forty minutes. What is the usual answer?

3. What happens once a team routinely merges with a red build?