* feat(focus-mode): focus screen UX overhaul Major rework of the focus mode timer screens (#7349): - Shared <focus-clock-face> drives Pomodoro / Flowtime / Countdown / Break with a single visual chrome; size tokens scale fluidly via clamp() + vmin/vh, no discrete breakpoints. - Single source of truth: --clock-time-size and --control-offset derive from --clock-face-size. - Countdown: click-to-edit duration, draggable handle on the ring, hybrid 5-min/15-min snap with 6h-per-rotation above 1h ([useFlexibleIncrement] on input-duration-slider, opt-in for other consumers). - Pomodoro prep inherits the click-to-type input; drag handle hidden so dragging the ring can't silently shift the value. - Pause keeps the selected task on screen (displayedTask falls back to the paused task while currentTask is null). - Notes panel acts as a modal: clock stays put, backdrop dims and closes on outside-click. - Session controls row below the circle (pause / complete / reset cycles); buttons fade via shared --revealed-opacity gated on host hover + document.hasFocus(). - Break screen mirrors focus-mode-main layout; cycle counter inside the circle on both focus and break; back-to-planning unified. - Flowtime settings dialog: all fields render with proper disable/enable, stable dialog width when switching modes. - arrow_backward -> arrow_back: fixes glitched glyph in repeat-type context menus (boards, simple counters, take-a-break, flowtime). * fix(focus-mode): silence naming-convention lint on formly 'props.disabled' Formly's expressionProperties path-string keys ('props.disabled') aren't camelCase and the rule has no requiresQuotes exemption; matches the existing pattern in src/app/features/issue/common-issue-form-stuff.const.ts. * test(focus-mode): mock pomodoroConfig signal on FocusModeService The component's initialization effect now reads focusModeService.pomodoroConfig() in Pomodoro+Preparation mode, but the three mocked FocusModeService instances in the spec didn't provide it, causing TypeError in 47 tests on CI (somehow not surfaced locally). * test(focus-mode): align specs with unified back-to-planning flow - focus-mode-break.spec: exitBreakToPlanning -> cancelFocusSession - focus-mode-session-done.spec: drop obsolete hideFocusOverlay assertion (cancelFocusSession now handles both clearing tracking and hiding the overlay, matching the production component) - focus-mode-main.spec: storeSpy gains selectSignal returning a signal, needed by the displayedTask paused-task fallback * fix(focus-mode): restore E2E selector hooks on refactored controls The shared <focus-clock-face> refactor moved pause/complete buttons out of the clock face into a new .circle-controls row but didn't carry the class names forward; 23 E2E specs key off them. Also re-add .task-title-placeholder on the no-task FAB so prep-state checks find it. - .pause-resume-btn on pause/resume in focus-mode-main + focus-mode-break - .complete-session-btn on the done_all button in focus-mode-main - .task-title-placeholder added to .select-task-cta FAB * fix(focus-mode): aria-label icon buttons; align break E2Es with new flow - focus-mode-break: pause/resume/skip/reset icon buttons now carry [attr.aria-label] in addition to matTooltip — icon ligature alone isn't an accessible name and breaks getByRole locators. - pomodoro-break-timing-bug-6044.spec: skipButton uses getByRole with accessible name rather than hasText (mat-icon ligature is "skip_next", not "skip break"). - focus-mode-break.spec: "exit break to planning and change timer mode" and "Back to Planning should NOT auto-start next session" now match the unified back-to-planning flow — overlay closes on click, user re-opens focus mode to change settings or verify prep state. * fix(focus-mode): address PR #7586 review feedback Maintainer review (johannesjo): - Debounce the Pomodoro work-duration write so editing it emits one synced config op instead of one per keystroke; flush on session start so a value typed inside the debounce window is not lost. (A1) - Replace the local ::ng-deep restyling of the shared input-duration-slider with opt-in [bareRing] and [hideHandle] inputs that own the chrome overrides in the slider's own styles; the four other consumers keep the default look. (A2) - Add unit tests for the flexible drag math (_setValueFromRotationFlex): the A<->B boundary anchoring at 55/60 min and both +/-180 degree wrap branches. (A3) - Delete the orphaned exitBreakToPlanning action, its stopTrackingOnExitBreakToPlanning$ effect, reducer case and specs; cancelFocusSession already unsets the current task. (B1) - Drop the unreferenced CONTINUE_TO_NEXT_SESSION and BREAK_RELAX_MSG i18n keys. (B2) - Collapse the duplicated clock-size clamp() into a single --clock-face-size-default token. (B4) Smaller focus-screen fixes (beerkumquatpome): - Hide the break task title when "pause tracking during breaks" is on. (C7) - Commit and close the duration editor on Enter. (C9) - Rename "Back to Planning" to "Exit focus session". (C11) - Show Flowtime breaks as a neutral "Break". (C13) Break-circle vertical alignment (C1) is only partially addressed here (matched the top reservation); exact alignment is a follow-up. * refactor(focus-mode): share a layout shell across timer screens and auto-start Flowtime breaks Extract a presentational focus-mode-layout component (4-row content-projection skeleton: [fmTop]/[fmTask]/[fmClock]/[fmBottom]) shared by the focus-session and break screens, so both keep a stable clock baseline across the focus<->break and prep<->in-progress transitions. focus-mode-main and focus-mode-break now consume the shell instead of each maintaining their own absolute layout. Replace the Flowtime "break offer" step with an auto-started break, mirroring Pomodoro: - Remove the BreakOffer UI state and the offerFlowtimeBreak action/reducer. - endFlowtimeSession now dispatches completeFocusSession(isManual:false) + startBreak (unsetting the task first when tracking-pause-on-break is on), so the break starts automatically and the session is logged exactly once via logFocusSession$. Also reorder the bottom controls (Back to Planning leftmost), restore the BACK_TO_PLANNING label to "Back to Planning", and drop the now-orphaned FLOWTIME_BREAK_TITLE / START_BREAK i18n keys. * test(layout): restore document.activeElement after focus-restoration specs The LayoutService "Focus restoration" tests override document.activeElement with Object.defineProperty, which shadows the native (inherited) getter with an own property on document. The afterEach only removed the mock DOM node, so the override leaked into later specs: once it ran, document.activeElement was frozen at the mock element and subsequent .focus() calls could no longer move it. Depending on Karma's spec order this broke the task.service focusTaskById tests (#7120), which then saw the stale activeElement instead of the element they focused. Delete the shadowing own property in afterEach to restore native behavior. Repro: ng test --include layout.service.spec.ts --include task.service.spec.ts * refactor(focus-mode): add interactive tracking widget and polish timer-screen layout - Replace the read-only task-tracking-info with focus-mode-task-tracking (vertical time stack + play/pause), wired through the shared layout shell - Center the task title and floor the task-row height so the clock baseline stays aligned across focus <-> break - Spacing polish: task-title-row and layout gaps to --s2, segmented-button-group padding to 0 - Drop redundant safe-area-bottom padding on the action row (the overlay already reserves it for the fixed shell) - Add "Take a moment to relax" break message and a clock-digit edit affordance * refactor(focus-mode): share timer/break layout, drop dead tracking toggle - Extract a shared <focus-mode-layout> skeleton and <focus-mode-task-row> used by both the focus session and the break. - Remove the in-view tracking play/pause toggle (start/stop stays on the global header button); strip focus-mode-task-tracking to read-only and drop RESUME_TRACKING. - Pin the mode selector out of flow and center the task·clock·bottom group; equal reserved task/bottom rows keep the clock vertically centered, with the selector kept on top. - Tighten sizing: horizontal selector segments, settings cog matched to the in-session controls, and a fluid clock clamp. |
||
|---|---|---|
| .. | ||
| constants | ||
| fixtures | ||
| helpers | ||
| pages | ||
| store-screenshots | ||
| store-video | ||
| tests | ||
| utils | ||
| .gitignore | ||
| CLAUDE.md | ||
| global-setup.ts | ||
| playwright.config.ts | ||
| playwright.store-screenshots.config.ts | ||
| playwright.store-screenshots.electron.config.ts | ||
| playwright.store-video.config.ts | ||
| README.md | ||
| tsconfig.json | ||
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
- Running Tests
- Test Structure
- Page Objects
- Common Patterns
- Selectors
- Wait Utilities
- Writing New Tests
- Best Practices
- Troubleshooting
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
│ ├── schedule.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
- Use page objects for all interactions
- Use centralized selectors from
constants/selectors.ts - Wait for Angular stability after state changes
- Use test prefixes (automatic via fixtures) for isolation
- Test one thing per test - keep tests focused
- Use descriptive test names - "should create task and mark as done"
- Clean up state - tests should be independent
- 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
- Don't hardcode selectors - use
cssSelectors - Don't use arbitrary waits - use
waitForAngularStability - Don't share state between tests - each test should be independent
- Don't access DOM directly - use page objects
- Don't skip error handling - tests should fail clearly
- Don't use
anytypes - 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"
- Check if selector is correct in
constants/selectors.ts - Add wait before interaction:
await waitForAngularStability(page) - Use
await element.waitFor({ state: 'visible' }) - Check if element is in a different context (iframe, shadow DOM)
Test Timeout
- Increase timeout in specific waitFor calls
- Check if Angular is stuck - look for pending HTTP requests
- Use
page.pause()to debug interactively - Check network tab for failed requests
Flaky Tests
- Add proper waits:
waitForAngularStability,waitForAppReady - Avoid
page.waitForTimeout()- use condition-based waits - Check for race conditions - ensure state is persisted
- Use
waitForStatePersistencebefore 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.tsfor 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
testandexpectfromfixtures/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)