Skip to content

Conversation

@suisuss
Copy link

@suisuss suisuss commented Feb 5, 2026

Summary

This PR establishes a comprehensive E2E testing infrastructure using Playwright, including CI integration and happy path test suites for core workflows.

New Infrastructure

  • GitHub Actions workflow (.github/workflows/e2e-tests.yml) - Runs E2E tests against staging/production with proper database setup
  • Playwright configuration - Configured for serial test execution with proper timeouts and database access
  • Test utilities (tests/e2e/playwright/utils/) - Reusable auth and workflow helpers with OTP verification from database

Test Suites Added

Suite Tests Coverage
auth.test.ts 9 Signup, signin, OTP verification, email validation
invitations.test.ts 10 Org invites, accept flows, membership management
organization-wallet.test.ts 11 Wallet creation, display, balance refresh
schedule-trigger.test.ts 6 Trigger node selection, workflow creation
workflow.test.ts 7 Canvas, node creation, action search
happy-paths/web3-balance.test.ts 4 Web3 balance check workflow
happy-paths/webhook-workflow.test.ts 4 Webhook trigger and execution
happy-paths/scheduled-workflow.test.ts 3 Scheduled workflow persistence

Code Quality

  • All test emails standardized to test+TIME@techops.services format
  • Regex patterns moved to module top-level per lint rules
  • Removed skipped tests for unimplemented routes (credentials, address-book)
  • All lint and type checks passing

Scripts Added

  • scripts/schedule-dispatcher.ts - Workflow schedule dispatcher
  • scripts/schedule-executor.ts - Workflow execution handler

Test plan

  • Verify CI workflow runs on PR
  • Run pnpm test:e2e locally against docker-compose setup
  • Confirm all 54 tests pass in CI environment

- Add unit/integration tests to PR checks workflow
- Create e2e-tests.yml workflow for E2E testing
- Add scheduler scripts (schedule-dispatcher, schedule-executor)
- Fix docker-compose for local dev scheduler
- Add Playwright happy path tests for core user journeys
- Add shared test utilities (auth, workflow helpers)
- Configure Playwright for deployed PR environment testing
- Add workflow_run trigger to run E2E against deployed PRs
- Exclude .worktrees from biome linting
- Remove skipped test files (credentials, address-book) for unimplemented routes
- Move inline regex patterns to module top-level per lint rules
- Fix nested ternary in playwright.config.ts
- Standardize all test emails to use test+TIME@techops.services format
- Fix import ordering in playwright.config.ts
@suisuss suisuss marked this pull request as draft February 5, 2026 04:16
- Use shared signUpAndVerify util with proper DATABASE_URL expansion
- Fix openCreateOrgForm to detect already-visible form
- Update input selectors from placeholder to id (#org-name, #org-slug)
- Make custom slug unique with timestamp to avoid conflicts
- Fix wallet overlay selector (doesn't have role=dialog)
- Increase wallet creation timeout for Para API
- Fix Balances heading locator
- Fix refresh button enabled state wait

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn't the initial idea to move the scheduler and dispatcher from this repo?

I noticed that some files we previously removed have been reintroduced in this PR. Regarding testing, I think each repository should have its own pipeline and testing suite. For the scheduler, we should mock the data we send from the API to verify that it interacts as expected.

Could you clarify the approach here and confirm whether these files should actually be in this repo? I referring specifically to scripts/schedule-dispatcher.ts and this particular one


on:
push:
branches: [main, staging, production]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a typo, our production branch is called prod

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, do we need tests in main? That branch is used to keep the upstream in sync, but it doesn’t include most of the newly introduced functionalities.


- **Test Address**: `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045` (vitalik.eth)
- **Test Network**: `mainnet`
- **Test Cron**: `0 * * * *` (hourly), `30 8 * * 1-5` (weekday mornings)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is related to a comment in the following files. Personally, I think we should rely on the infrastructure that can be run from this repository, such as webhooks and manual runs.

However, cron-based workflows should validate that the data we introduce is stored in the database as expected. The same applies to event-based workflows, since we rely on “external” services to complete the execution of the node.

Unless we set up the entire workflow by adding a pre-run step that clones both repositories into the pipeline and starts the required services, we won’t be able to fully cover these cases. That approach could be useful if we want full e2e coverage.

Otherwise, I would recommend focusing on integration tests using only what we can run within this repository.

headers: { "Content-Type": "application/json" },
});

expect(response.status()).toBeLessThan(500);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean we accept any status code below 500, including 4xx responses?

Comment on lines +241 to +258
// Create wallet
await overlay
.locator('button:has-text("Create Organization Wallet")')
.click();
await overlay.locator('button:has-text("Create Wallet")').click();

// Wait for wallet creation
await expect(
page
.locator("[data-sonner-toast]")
.filter({ hasText: WALLET_CREATED_PATTERN })
).toBeVisible({ timeout: 30_000 });

// Verify wallet address is displayed (format: 0x...xxxx)
await expect(overlay.locator("code")).toContainText(ADDRESS_PATTERN);

// Verify email is displayed
await expect(overlay.locator(`text=${email}`)).toBeVisible();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which Para credentials are we using to run this? Would increasing the number of users also risk exceeding the limits of our current Para plan?

Copy link

@joelorzet joelorzet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the review feedback, there are a couple things we should align on before merging: some files that we previously moved out of this repo have been reintroduced, and we need to be careful about how we're handling credentials for the paid services included in the tests.

Also, I think moving forward each new functionality should include tests, whether unit or integration. This would really help with continuous and async work, as each developer can make clear what their changes are intended to do through tests, and it ensures we're not introducing breaking changes to existing functionality unless they're explicitly required by a ticket or request.

That said, the tests themselves are a solid foundation and provide a good entry point for expanding our coverage across the app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants