super-productivity/e2e
Johannes Millan fe3b97524a
feat(planner): integrate recurring config into schedule dialog (#9286)
* feat(planner): add Repeat button to schedule dialog

Surface recurrence directly from the schedule dialog via a "Repeat"
button that opens the existing repeat-config dialog, so setting a task
to recur no longer requires the separate detail-panel row.

- Button mirrors the repeat dialog's own start-date button styling and
  shows the live recurrence label ("Daily", "Mon–Fri", ...) or
  "Does not repeat", with an edit/chevron affordance.
- Gated to top-level, non-issue tasks (matching the panel's Repeat row)
  and hidden in isSelectDueOnly mode to avoid a circular picker.
- Recurrence start is seeded from the date currently selected in the
  dialog, falling back to the task's due day / creation date.
- Label reads the repeat cfg via the store selector (not the service)
  to keep the dialog's dependency surface minimal.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176AgeeX2Tzv3KjmwZ7zWXC

* feat(tasks): merge recurring into the schedule item in task detail panel

Fold the standalone "Repeat" row into the schedule/due item so a task's
timing lives in one place. The schedule item now also shows the
recurrence label (e.g. "Daily") beside the due date, and recurrence is
edited via the Repeat button now hosted in the schedule dialog.

- Remove the separate Repeat row and the now-unused editTaskRepeatCfg()
  opener; recurrence editing goes through the schedule dialog.
- Show a repeat chip in the schedule item's value when repeatCfgId is
  set, and treat repeatCfgId as "has a value" for the add/edit icon.
- showScheduleIcon() falls back to 'repeat' for a recurring task with no
  due date instead of the misleading 'alarm'.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176AgeeX2Tzv3KjmwZ7zWXC

* style(datetime-picker): tighten spacing in the schedule picker

The date/time picker left noticeable dead space between the calendar and
the time input, and between the stacked time and reminder inputs.

- Shrink the fixed calendar height 400px -> 360px. A 6-row month (the
  structural max) needs ~353px, so the old value left ~47px of empty
  space below the grid; 360px fits every month with no clipping.
- Drop the calendar-to-inputs top margin and the reserved Material
  form-field subscript row (these fields never show hints and always
  carry a valid value), so the time and reminder inputs sit closer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176AgeeX2Tzv3KjmwZ7zWXC

* style(tasks): stack recurrence under the due date in the schedule item

When a task was both planned and recurring, the schedule item crammed
the date ("Today") and the recurrence ("Every day") side by side in the
narrow value column, squeezing both and truncating the recurrence label.

Present them as a hierarchy instead: the due date is the primary value
and the recurrence is a muted secondary line stacked beneath it. Reads
clearly, avoids truncation, and gives the row label room to breathe.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176AgeeX2Tzv3KjmwZ7zWXC

* style(datetime-picker): unify vertical spacing below the inputs

The form-ctrl-wrapper carried a bottom margin on top of each field's own
~16px trailing space, so whatever followed the inputs sat 32px away —
twice the gap between the stacked fields themselves. In the schedule
dialog this left the Repeat button visibly detached; the deadline dialog
had the same doubled gap before its actions.

Drop the redundant bottom margin so the inputs, the Repeat button, and
the dialog actions all share one consistent 16px rhythm.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176AgeeX2Tzv3KjmwZ7zWXC

* fix(planner): harden schedule-dialog recurrence + polish merged item

Review follow-ups across the recurring/planned consolidation:

- Fix a duplicate-cfg bug: openRepeatDialog seeded the repeat dialog from
  the frozen MAT_DIALOG_DATA snapshot, so re-opening after a repeat was
  just created routed to "create" again and orphaned the first cfg. Seed
  from the live store task instead, so the second open edits.
- Drop the ineffective "seed recurrence start from the selected date"
  logic and its misleading comment: the repeat dialog derives the start
  from the task's due date; targetDate only drives the skip-instance UI.
  Behaviour now matches task.component's opener exactly.
- Break the schedule-dialog <-> repeat-dialog module cycle with a lazy
  import, matching task.component / add-task-bar.
- Panel: give the recurrence line a screen-reader "Repeat:" prefix
  (cdk-visually-hidden) and let long labels ellipsis within the flex row.
- Align terminology: ADDITIONAL_INFO.REPEAT "Recur" -> "Repeat" (the
  add-task-bar and schedule dialog already say "Repeat").
- Use --bar-height token instead of a raw 48px in .repeat-btn.
- Add coverage: canRepeat gating (incl. isSelectDueOnly), the live-task
  seeding regression, and showScheduleIcon's new 'repeat' branch.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176AgeeX2Tzv3KjmwZ7zWXC

* test(recurring): follow schedule dialog repeat flow

Update shared Playwright helpers and direct callers after the standalone Repeat row moved into the schedule dialog.

* style(planner): remove one-off Material overrides

Use stock button presentation and the supported dynamic subscript API instead of local Material internals.

* style(planner): distinguish configured repeat values

Emphasize active recurrence while keeping the non-repeating state visibly muted.

* fix(recurring): avoid warning for newly added config

Require removal confirmation only when recurrence already existed before the enclosing schedule dialog opened.

* fix(recurring): preserve schedule context in repeat dialog

Seed new repeat configs from the current Schedule selection and suppress removal confirmation only for the exact config created in that dialog session.

Update the repeating-task guide and add regression coverage for date and config provenance.

* test(recurring): target combined schedule value

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-07-24 15:49:12 +02:00
..
constants chore(ui): removes dead components and features [#8260 - Tier A] (#8889) 2026-07-10 11:40:35 +02:00
electron fix(electron): handle special characters in install paths (#9257) 2026-07-23 11:43:56 +02:00
fixtures fix(onboarding): improve productivity preset and mobile first-task flow (#9288) 2026-07-24 15:28:08 +02:00
helpers fix(sync): isolate provider encryption settings + enforce critical e2e coverage (#9044) 2026-07-15 14:24:49 +02:00
pages test(project): guard project navigation route detection (#9103) 2026-07-17 11:59:08 +02:00
pwa test: close critical E2E and CI coverage gaps (#9274) 2026-07-24 10:57:29 +02:00
store-screenshots feat(focus-mode): make preparation opt-in, smooth start transition (#8639) 2026-06-29 19:44:53 +02:00
store-video feat(tasks): redesign add-task-bar layout, toggles, note field & a11y (#8812) 2026-07-07 16:26:36 +02:00
tests feat(planner): integrate recurring config into schedule dialog (#9286) 2026-07-24 15:49:12 +02:00
utils feat(planner): integrate recurring config into schedule dialog (#9286) 2026-07-24 15:49:12 +02:00
.gitignore fix(gitignore): correct screenshots directory path in .gitignore 2026-01-21 21:05:29 +01:00
CLAUDE.md docs: trim CLAUDE.md and split E2E reference into e2e/CLAUDE.md 2026-05-01 23:04:03 +02:00
global-setup.ts test(e2e): harden failure signals and provider gates (#7753) 2026-05-23 20:33:04 +02:00
playwright.config.ts test: close critical E2E and CI coverage gaps (#9274) 2026-07-24 10:57:29 +02:00
playwright.pwa.config.ts test: close critical E2E and CI coverage gaps (#9274) 2026-07-24 10:57:29 +02:00
playwright.store-screenshots.config.ts test(screenshots): stabilize electron screenshot output 2026-05-09 14:38:49 +02:00
playwright.store-screenshots.electron.config.ts test(screenshots): stabilize electron screenshot output 2026-05-09 14:38:49 +02:00
playwright.store-video.config.ts feat(video): Playwright-driven marketing reel pipeline 2026-05-07 23:08:24 +02:00
README.md chore(ui): removes dead utilities and op-log leftovers [#8260 - Tier A] (#8892) 2026-07-11 13:05:34 +02:00
tsconfig.json refactor: move tests 2025-08-02 11:37:25 +02:00

E2E Testing Guide for Super Productivity

This guide provides comprehensive information for writing and maintaining end-to-end tests for Super Productivity using Playwright.

Table of Contents


Overview

Our E2E tests are built with Playwright and follow the Page Object Model (POM) pattern for maintainability and reusability. Tests are organized by feature and use shared fixtures for common setup.

Key Technologies

  • Playwright: Modern E2E testing framework
  • TypeScript: Type-safe test code
  • Page Object Model: Encapsulates page interactions
  • Fixtures: Shared setup and utilities

Running Tests

Basic Commands

# Run all tests
npm run e2e

# Run tests in UI mode (interactive)
npm run e2e:ui

# Run a single test file with detailed output
npm run e2e:file tests/task-basic/task-crud.spec.ts

# Run tests in headed mode (see browser)
npm run e2e:headed

# Run tests in debug mode
npm run e2e:debug

# Show test report
npm run e2e:show-report

WebDAV Sync Tests

# Run WebDAV tests (starts Docker container)
npm run e2e:webdav

Test Structure

Directory Layout

e2e/
├── constants/          # Shared selectors and constants
│   └── selectors.ts    # Centralized CSS selectors
├── fixtures/           # Test fixtures and setup
│   └── test.fixture.ts # Custom test fixtures with page objects
├── helpers/            # Test helper functions
│   └── plugin-test.helpers.ts
├── pages/              # Page Object Models
│   ├── base.page.ts    # Base page with common methods
│   ├── work-view.page.ts
│   ├── project.page.ts
│   ├── task.page.ts
│   ├── settings.page.ts
│   ├── dialog.page.ts
│   ├── planner.page.ts
│   ├── side-nav.page.ts
│   ├── sync.page.ts
│   ├── tag.page.ts
│   └── note.page.ts
├── tests/              # Test specifications
│   ├── task-basic/
│   ├── project/
│   ├── planner/
│   └── ...
├── utils/              # Utility functions
│   ├── waits.ts        # Wait helpers
│   └── sync-helpers.ts
├── playwright.config.ts
└── global-setup.ts

Page Objects

Page Objects encapsulate interactions with specific pages or components. All page objects extend BasePage and receive a page and optional testPrefix.

Available Page Objects

1. BasePage (base.page.ts)

Base class for all page objects. Provides common functionality:

class BasePage {
  async addTask(taskName: string): Promise<void>;
  // Adds a task with automatic test prefix
}

Example:

await workViewPage.addTask('My Task');
// Creates task with name "W0-P0-My Task" (prefixed for isolation)

2. WorkViewPage (work-view.page.ts)

Interactions with the main work view:

class WorkViewPage extends BasePage {
  async waitForTaskList(): Promise<void>;
  async addSubTask(task: Locator, subTaskName: string): Promise<void>;
}

Example:

await workViewPage.waitForTaskList();
await workViewPage.addTask('Parent Task');
const task = page.locator('task').first();
await workViewPage.addSubTask(task, 'Child Task');

3. TaskPage (task.page.ts)

Task-specific operations:

class TaskPage extends BasePage {
  getTask(index: number): Locator;
  getTaskByText(text: string): Locator;
  async markTaskAsDone(task: Locator): Promise<void>;
  async editTaskTitle(task: Locator, newTitle: string): Promise<void>;
  async openTaskDetail(task: Locator): Promise<void>;
  async getTaskCount(): Promise<number>;
  async isTaskDone(task: Locator): Promise<boolean>;
  getDoneTasks(): Locator;
  getUndoneTasks(): Locator;
  async waitForTaskWithText(text: string): Promise<Locator>;
  async taskHasTag(task: Locator, tagName: string): Promise<boolean>;
}

Example:

const task = taskPage.getTask(1); // First task
await taskPage.markTaskAsDone(task);
await expect(taskPage.getDoneTasks()).toHaveCount(1);

4. ProjectPage (project.page.ts)

Project management:

class ProjectPage extends BasePage {
  async createProject(projectName: string): Promise<void>;
  async navigateToProjectByName(projectName: string): Promise<void>;
  async createAndGoToTestProject(): Promise<void>;
  async addNote(noteContent: string): Promise<void>;
  async archiveDoneTasks(): Promise<void>;
}

Example:

await projectPage.createProject('My Project');
await projectPage.navigateToProjectByName('My Project');
await projectPage.addNote('Project notes here');

5. SettingsPage (settings.page.ts)

Settings and configuration:

class SettingsPage extends BasePage {
  async navigateToSettings(): Promise<void>;
  async expandSection(sectionSelector: string): Promise<void>;
  async expandPluginSection(): Promise<void>;
  async navigateToPluginSettings(): Promise<void>;
  async enablePlugin(pluginName: string): Promise<boolean>;
  async disablePlugin(pluginName: string): Promise<boolean>;
  async isPluginEnabled(pluginName: string): Promise<boolean>;
  async uploadPlugin(pluginPath: string): Promise<void>;
}

Example:

await settingsPage.navigateToPluginSettings();
await settingsPage.enablePlugin('Test Plugin');
expect(await settingsPage.isPluginEnabled('Test Plugin')).toBeTruthy();

6. DialogPage (dialog.page.ts)

Dialog and modal interactions:

class DialogPage extends BasePage {
  async waitForDialog(): Promise<Locator>;
  async waitForDialogToClose(): Promise<void>;
  async clickDialogButton(buttonText: string): Promise<void>;
  async clickSaveButton(): Promise<void>;
  async fillDialogInput(selector: string, value: string): Promise<void>;
  async fillMarkdownDialog(content: string): Promise<void>;
  async saveMarkdownDialog(): Promise<void>;
  async editDateTime(dateValue?: string, timeValue?: string): Promise<void>;
}

Example:

await dialogPage.waitForDialog();
await dialogPage.fillDialogInput('input[name="title"]', 'New Title');
await dialogPage.clickSaveButton();
await dialogPage.waitForDialogToClose();

Common Patterns

Pattern 1: Basic Task CRUD

test('should create and edit task', async ({ page, workViewPage, taskPage }) => {
  await workViewPage.waitForTaskList();

  // Create
  await workViewPage.addTask('Test Task');
  await expect(taskPage.getAllTasks()).toHaveCount(1);

  // Edit
  const task = taskPage.getTask(1);
  await taskPage.editTaskTitle(task, 'Updated Task');
  await expect(taskPage.getTaskTitle(task)).toContainText('Updated Task');

  // Mark as done
  await taskPage.markTaskAsDone(task);
  await expect(taskPage.getDoneTasks()).toHaveCount(1);
});

Pattern 2: Project Workflow

test('should create project and add tasks', async ({ projectPage, workViewPage }) => {
  await projectPage.createAndGoToTestProject();
  await workViewPage.addTask('Project Task 1');
  await workViewPage.addTask('Project Task 2');
  await expect(page.locator('task')).toHaveCount(2);
});

Pattern 3: Settings Configuration

test('should enable plugin', async ({ settingsPage, waitForNav }) => {
  await settingsPage.navigateToPluginSettings();
  await settingsPage.enablePlugin('My Plugin');
  await waitForNav();
  expect(await settingsPage.isPluginEnabled('My Plugin')).toBeTruthy();
});

Pattern 4: Dialog Interactions

test('should edit date in dialog', async ({ taskPage, dialogPage }) => {
  const task = taskPage.getTask(1);
  await taskPage.openTaskDetail(task);

  const dateInfo = dialogPage.getDateInfo('Created');
  await dateInfo.click();
  await dialogPage.editDateTime('12/25/2025', undefined);
  await dialogPage.clickSaveButton();
});

Selectors

All selectors are centralized in constants/selectors.ts. Always use these constants instead of hardcoding selectors in tests.

Using Selectors

import { cssSelectors } from '../constants/selectors';

const { TASK, TASK_TITLE, TASK_DONE_BTN } = cssSelectors;

// In test:
const task = page.locator(TASK).first();
const title = task.locator(TASK_TITLE);

Selector Categories

  • Navigation: SIDENAV, NAV_ITEM, SETTINGS_BTN
  • Layout: ROUTE_WRAPPER, BACKDROP, PAGE_TITLE
  • Tasks: TASK, TASK_TITLE, TASK_DONE_BTN, SUB_TASK
  • Add Task: ADD_TASK_INPUT, ADD_TASK_SUBMIT
  • Dialogs: MAT_DIALOG, DIALOG_FULLSCREEN_MARKDOWN
  • Settings: PAGE_SETTINGS, PLUGIN_SECTION, PLUGIN_MANAGEMENT
  • Projects: PAGE_PROJECT, CREATE_PROJECT_BTN, WORK_CONTEXT_MENU

Wait Utilities

Located in utils/waits.ts, these utilities help handle Angular's async nature.

Available Wait Functions

waitForAngularStability(page, timeout?)

Waits for Angular to finish all async operations.

await waitForAngularStability(page);

waitForAppReady(page, options?)

Comprehensive wait for app initialization.

await waitForAppReady(page, {
  selector: 'task-list',
  ensureRoute: true,
  routeRegex: /#\/project\/\w+/,
});

waitForStatePersistence(page)

Waits for IndexedDB persistence to complete (important before sync operations).

await workViewPage.addTask('Task');
await waitForStatePersistence(page); // Ensure saved to IndexedDB
// Now safe to trigger sync

Writing New Tests

Step 1: Create Test File

// e2e/tests/my-feature/my-feature.spec.ts
import { test, expect } from '../../fixtures/test.fixture';

test.describe('My Feature', () => {
  test('should do something', async ({ page, workViewPage, taskPage }) => {
    // Test code here
  });
});

Step 2: Use Page Objects

test('my test', async ({ workViewPage, taskPage, dialogPage }) => {
  // Wait for page ready
  await workViewPage.waitForTaskList();

  // Use page objects for interactions
  await workViewPage.addTask('Task 1');
  const task = taskPage.getTask(1);
  await taskPage.markTaskAsDone(task);

  // Assertions
  await expect(taskPage.getDoneTasks()).toHaveCount(1);
});

Step 3: Handle Waits Properly

// GOOD: Use Angular stability waits
await workViewPage.addTask('Task');
await waitForAngularStability(page);
await expect(page.locator('task')).toBeVisible();

// BAD: Arbitrary timeouts
await page.waitForTimeout(5000); // Avoid unless necessary

Step 4: Use Selectors from Constants

import { cssSelectors } from '../../constants/selectors';

const { TASK, TASK_TITLE } = cssSelectors;
const title = page.locator(TASK).first().locator(TASK_TITLE);

Best Practices

DO

  1. Use page objects for all interactions
  2. Use centralized selectors from constants/selectors.ts
  3. Wait for Angular stability after state changes
  4. Use test prefixes (automatic via fixtures) for isolation
  5. Test one thing per test - keep tests focused
  6. Use descriptive test names - "should create task and mark as done"
  7. Clean up state - tests should be independent
  8. Use role-based selectors when possible (accessibility)
// GOOD
await page.getByRole('button', { name: 'Save' }).click();

// LESS GOOD
await page.locator('.save-btn').click();

DON'T

  1. Don't hardcode selectors - use cssSelectors
  2. Don't use arbitrary waits - use waitForAngularStability
  3. Don't share state between tests - each test should be independent
  4. Don't access DOM directly - use page objects
  5. Don't skip error handling - tests should fail clearly
  6. Don't use any types - maintain type safety

Test Isolation

Each test gets:

  • Isolated browser context (clean storage)
  • Unique test prefix (W0-P0-, W1-P0-, etc.)
  • Fresh page instance

This ensures tests don't interfere with each other.

Handling Flakiness

// Use waitFor with explicit conditions
await page.waitForFunction(() => document.querySelectorAll('task').length === 3, {
  timeout: 10000,
});

// Use locator assertions (auto-retry)
await expect(page.locator('task')).toHaveCount(3);

// Avoid fixed timeouts
await page.waitForTimeout(1000); // BAD
await waitForAngularStability(page); // GOOD

Troubleshooting

Test Fails with "Element not found"

  1. Check if selector is correct in constants/selectors.ts
  2. Add wait before interaction: await waitForAngularStability(page)
  3. Use await element.waitFor({ state: 'visible' })
  4. Check if element is in a different context (iframe, shadow DOM)

Test Timeout

  1. Increase timeout in specific waitFor calls
  2. Check if Angular is stuck - look for pending HTTP requests
  3. Use page.pause() to debug interactively
  4. Check network tab for failed requests

Flaky Tests

  1. Add proper waits: waitForAngularStability, waitForAppReady
  2. Avoid page.waitForTimeout() - use condition-based waits
  3. Check for race conditions - ensure state is persisted
  4. Use waitForStatePersistence before operations that depend on saved state

Debugging

// Pause execution and open Playwright Inspector
await page.pause();

// Take screenshot
await page.screenshot({ path: 'debug.png' });

// Console log page content
console.log(await page.content());

// Get element text for debugging
const text = await page.locator('task').first().textContent();
console.log('Task text:', text);

Running Single Test

# Run specific file
npm run e2e:file tests/task-basic/task-crud.spec.ts

# Run in debug mode
npm run e2e:debug

# Run in headed mode to see browser
npm run e2e:headed

Examples

Example 1: Full Task CRUD Test

import { test, expect } from '../../fixtures/test.fixture';

test.describe('Task CRUD', () => {
  test('should create, edit, and delete tasks', async ({
    page,
    workViewPage,
    taskPage,
  }) => {
    await workViewPage.waitForTaskList();

    // Create
    await workViewPage.addTask('Task 1');
    await workViewPage.addTask('Task 2');
    await expect(taskPage.getAllTasks()).toHaveCount(2);

    // Edit
    const firstTask = taskPage.getTask(1);
    await taskPage.editTaskTitle(firstTask, 'Updated Task');
    await expect(taskPage.getTaskTitle(firstTask)).toContainText('Updated Task');

    // Mark as done
    await taskPage.markTaskAsDone(firstTask);
    await expect(taskPage.getDoneTasks()).toHaveCount(1);
    await expect(taskPage.getUndoneTasks()).toHaveCount(1);
  });
});

Example 2: Project Workflow

test('should create project with tasks', async ({
  projectPage,
  workViewPage,
  taskPage,
}) => {
  await projectPage.createAndGoToTestProject();

  await workViewPage.addTask('Project Task');
  await projectPage.addNote('Important notes');

  const task = taskPage.getTask(1);
  await taskPage.markTaskAsDone(task);

  await projectPage.archiveDoneTasks();
  await expect(taskPage.getUndoneTasks()).toHaveCount(0);
});

Example 3: Settings Test

test('should configure plugin', async ({ settingsPage, page }) => {
  await settingsPage.navigateToPluginSettings();

  const pluginExists = await settingsPage.pluginExists('Test Plugin');
  expect(pluginExists).toBeTruthy();

  await settingsPage.enablePlugin('Test Plugin');
  expect(await settingsPage.isPluginEnabled('Test Plugin')).toBeTruthy();

  await settingsPage.navigateBackToWorkView();
  await expect(page).toHaveURL(/tag\/TODAY/);
});

Getting Help

  • Check existing tests in e2e/tests/ for examples
  • Review page objects in e2e/pages/ for available methods
  • Look at constants/selectors.ts for available selectors
  • Use Playwright Inspector (npm run e2e:debug) for debugging
  • Check Playwright docs: https://playwright.dev/

Summary Checklist

When writing a new test:

  • Create test file in appropriate tests/ subdirectory
  • Import test and expect from fixtures/test.fixture.ts
  • Use page objects for all interactions
  • Use selectors from constants/selectors.ts
  • Add proper waits (waitForAngularStability, etc.)
  • Use descriptive test names
  • Ensure test is isolated (no shared state)
  • Run test locally before committing
  • Test passes consistently (run 3+ times)