Skip to content

Run headless tests on todoApp production build #2707

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 39 commits into from
May 19, 2025

Conversation

infomiho
Copy link
Contributor

@infomiho infomiho commented Apr 28, 2025

Updates the todoApp to be able to run headless tests in the CI.

Closes #884

@infomiho infomiho marked this pull request as ready for review April 29, 2025 11:13
@infomiho infomiho requested a review from Copilot April 29, 2025 11:16
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR enables headless testing on the todoApp production build by introducing a manual email verification step and updating the CI configuration. Key changes include:

  • A new HeadlessVerifyEmails page and corresponding headless server operation for verifying user emails.
  • Modifications to multiple Playwright test files to include an email verification step.
  • Updates to the Playwright configuration and CI workflow to support different test modes (dev/build).

Reviewed Changes

Copilot reviewed 9 out of 13 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/pages/HeadlessVerifyEmails.tsx New page component to manually trigger user email verification.
src/auth/headless.ts Added server-side operation to iterate and verify user emails.
headless-tests/tests/user-api.spec.ts Updated test to include email verification after signup.
headless-tests/tests/simple.spec.ts Added email verification to simple spec tests.
headless-tests/tests/helpers.ts Introduced performEmailVerification helper for tests.
headless-tests/tests/crud.spec.ts Integrated email verification call in CRUD tests.
headless-tests/tests/auth-hooks.spec.ts Updated auth hooks tests with email verification steps.
headless-tests/playwright.config.ts Added HEADLESS_TEST_MODE variable to toggle test modes.
.github/workflows/waspc-ci.yaml Expanded CI workflow to run headless tests in both dev and build modes.
Files not reviewed (4)
  • waspc/examples/todoApp/.env.server.example: Language not supported
  • waspc/examples/todoApp/.env.server.headless: Language not supported
  • waspc/examples/todoApp/main.wasp: Language not supported
  • waspc/examples/todoApp/package-lock.json: Language not supported
Comments suppressed due to low confidence (3)

waspc/examples/todoApp/src/pages/HeadlessVerifyEmails.tsx:5

  • [nitpick] Consider simplifying the onClick handler by passing verifyAllUserEmails directly instead of wrapping it in an arrow function.
<button onClick={() => verifyAllUserEmails()} className="btn btn-primary">

waspc/examples/todoApp/src/auth/headless.ts:42

  • [nitpick] If this logging is intended for production, consider using a proper logging utility to ensure sensitive data is handled securely.
console.log('Verifying email for user:', emailProviderId.providerUserId)

waspc/examples/todoApp/headless-tests/playwright.config.ts:3

  • [nitpick] Add a comment explaining the allowed values ('dev' or 'build') for HEADLESS_TEST_MODE to aid future maintainers.
const HEADLESS_TEST_MODE = process.env.HEADLESS_TEST_MODE ?? 'dev'

@infomiho infomiho requested review from sodic and FranjoMindek April 29, 2025 14:27
Copy link
Contributor

@FranjoMindek FranjoMindek left a comment

Choose a reason for hiding this comment

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

Small nudges.

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we run this test only in production code then?

Copy link
Contributor Author

@infomiho infomiho May 2, 2025

Choose a reason for hiding this comment

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

We can't really run any tests without logging in first. And I think we should be running tests on the production builds because we do it manually. So we need to find a way to verify the email.

The problem here is the email verification flow, so either we "brute force" it like we did here or we come up with a way to have a local SMTP server to get the verification email and click on the verify link. Now that I said it - let me see if I can get that up and running.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added a local SMTP server to avoid modifying the todoApp to be able to verify the email: cc4de83 (#2707)

Copy link
Contributor

Choose a reason for hiding this comment

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

I've meant in this way, which I see you've added. My bad if I had bad wording.

  if (process.env.HEADLESS_TEST_MODE === 'dev') {
    // In dev mode, the emails are verified automatically
    return
  }

But the SMTP change is nice.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wanted to say should we compile this part of the application only when running production code headless tests, but little hard to do without main.wasp.ts. Looking forward to when we transition.

@@ -29,6 +30,8 @@ export async function startAppInBuildMode({
pathToApp,
});

await startLocalSmtpServer();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm starting an SMTP server when running in the build mode only. Should we do it in the dev mode as well? I'm not sure what would be the use in dev mode.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't really see a reason to do it in dev mode.
In a way this further simulates build environment, which we wanted to do. So I think it fits build only.

Comment on lines 30 to 33
if (process.env.HEADLESS_TEST_MODE === 'dev') {
// In dev mode, the emails are verified automatically
return
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This relies on the todoApp having SKIP_EMAIL_VERIFICATION_IN_DEV in its env vars (which we do have in the .env.server.headless file)

Copy link
Contributor

Choose a reason for hiding this comment

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

Please add this comment to the code too

import { spawnWithLog } from "./process.js";
import { log } from "./logging.js";

export async function startLocalSmtpServer(): Promise<void> {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do we want to have this in the wasp-app-runner?

Alternatively, we could run the Mailcrab SMTP server just in the Wasp CI.

Having it in the wasp-app-runner gives a unified way to test all the example apps that require email verification.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather it not depends on an external service.
I think Filip can give more input here when he reviews it.
For me this is okay for testing purposes.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess if we're starting the database, we can start this too.

A good rule of thumb is: if the dev mode can simulate the feature (e.g., database with sqlite or wasp start db, email verification with CLI output), then so should the build mode.

Copy link
Contributor

@FranjoMindek FranjoMindek left a comment

Choose a reason for hiding this comment

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

I have nothing of value to add anymore

Copy link
Contributor

@sodic sodic left a comment

Choose a reason for hiding this comment

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

Awesome, looks good to me!

Just take care of this please: #2707 (comment)

import { spawnWithLog } from "./process.js";
import { log } from "./logging.js";

export async function startLocalSmtpServer(): Promise<void> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess if we're starting the database, we can start this too.

A good rule of thumb is: if the dev mode can simulate the feature (e.g., database with sqlite or wasp start db, email verification with CLI output), then so should the build mode.

Comment on lines +19 to +20
if (exitCode !== 0) {
log("smtp-server", "error", `SMTP server exited with code ${exitCode}`);
Copy link
Contributor

@sodic sodic May 6, 2025

Choose a reason for hiding this comment

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

This is a nice example of localized logs and their prefixes (I talked about that in the other PR).

Usually, I'd recommend all process.exit calls to be at the top level (i.e., bubble up the error and exit at the top). But I think we can let it slide in wasp-app-runner.

@@ -21,7 +22,7 @@ test.describe('auth hooks', () => {
})

await expect(page.locator('body')).toContainText(
'On Before Signup Hook disallows this email.',
'On Before Signup Hook disallows this email.'
Copy link
Contributor

Choose a reason for hiding this comment

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

Aw man, I liked the trailing comma rule :(

Why'd we lose it?

Copy link
Contributor

@FranjoMindek FranjoMindek May 6, 2025

Choose a reason for hiding this comment

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

prettier's all vs es5, comment on universal styles PR if you want to influence this

Copy link
Contributor

Choose a reason for hiding this comment

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

Fine, I'll fight this battle again.

Comment on lines 30 to 33
if (process.env.HEADLESS_TEST_MODE === 'dev') {
// In dev mode, the emails are verified automatically
return
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Please add this comment to the code too

@infomiho infomiho force-pushed the miho-run-wasp-build-output branch from b96e808 to e5d2552 Compare May 9, 2025 17:01
Base automatically changed from miho-run-wasp-build-output to miho-runner-build-feature May 19, 2025 09:50
@infomiho infomiho changed the base branch from miho-runner-build-feature to main May 19, 2025 10:01
@infomiho infomiho changed the base branch from main to miho-runner-build-feature May 19, 2025 10:01
@infomiho infomiho force-pushed the miho-wasp-build-todo-ci branch from 24d319d to c544a16 Compare May 19, 2025 11:39
@infomiho infomiho merged commit a05cd76 into miho-runner-build-feature May 19, 2025
5 checks passed
@infomiho infomiho deleted the miho-wasp-build-todo-ci branch May 19, 2025 11:54
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.

3 participants