```
You are an expert QA engineer. Your task is to write comprehensive E2E tests using Playwright for a pull request that updates our application's nodemailer dependency from version 7 to version 8.

The primary goal is to ensure that all user flows involving email functionality remain intact and are not broken by this major dependency upgrade. Pay close attention to the breaking changes noted in the release logs and potential security vulnerabilities that have been patched.

1. Context Summary

• PR Description: The PR is a dependency bump for nodemailer from v7.0.11 to v8.0.5. nodemailer is the library our application (studio.giselles.ai) uses to send all transactional emails.
• Key Risk: This is a major version update, which introduces breaking changes. The release notes explicitly mention one: the error code 'NoAuth' has been renamed to 'ENOAUTH'. Our backend error handling might be affected, leading to unhandled exceptions. Additionally, several security fixes related to SMTP command injection have been applied.
• Critical Paths to Test: We must validate every single user flow that triggers an email. This includes, but is not limited to:
  • User Registration / Account Creation (Welcome Email)
  • Password Reset Flow
  • "Contact Us" or support form submissions
  • User invitation emails

2. Test Scenarios

Create E2E tests covering the following scenarios. All tests must verify not only the UI feedback but also the actual email delivery and content using a mock email server.

Test File: Create a new test file named e2e/email-functionality.spec.ts.

Happy Path Scenarios:

1. User Registration:

   • Description: A new user signs up for an account.
   • Steps: Navigate to the registration page, fill in user details with a unique email, and submit the form.
   • Verification:
     • Assert that the user sees a success message on the UI.
     • Assert that one email is sent to the user's address.
     • Assert the email subject is Welcome to Giselle's Studio!.
     • Assert the email body contains a welcome message and confirms the username.

2. Password Reset:

   • Description: An existing user requests a password reset link.
   • Steps: Navigate to the "Forgot Password" page, enter the user's email, and submit.
   • Verification:
     • Assert the UI shows a confirmation message like "If an account exists, a reset link has been sent."
     • Assert that one email is sent to the user's address.
     • Assert the email subject is Reset Your Password.
     • Assert the email body contains a unique password reset link/token.

Edge Cases & Security Scenarios:

1. Password Reset for Non-Existent User:

   • Description: A password reset is requested for an email address not in the system.
   • Steps: Navigate to the "Forgot Password" page, enter a non-existent email address (e.g., nonexistent-user-${Date.now()}@test.com), and submit.
   • Verification:
     • Assert the UI shows the exact same confirmation message as the happy path to prevent email enumeration.
     • Assert that NO email is sent to that address.

2. Input Sanitization (SMTP Injection Attempt):

   • Description: Test the fixes for SMTP command injection (GHSA-vvjj-xcjg-gr5g).
   • Steps: In a form that sends an email (e.g., Registration or Contact Us), use an input field with carriage return/line feed characters.
   • Example: For the "Full Name" field, input: Test\r\nUser. For an email field, input: test\r\[email protected].
   • Verification:
     • The application should not crash or throw a 500 error.
     • The application should either reject the input with a validation error OR successfully send an email with the malicious characters sanitized (e.g., the recipient is [email protected], not test).
     • Verify the received email in the mock mail server to ensure its headers and body are not malformed.

Regression & Error Handling:

1. Email Service Failure:
   • Description: Test the application's graceful handling of email sending failures. This indirectly tests the NoAuth -> ENOAUTH breaking change, as misconfigured error handling on the backend could lead to a frontend crash.
   • Setup: In this specific test, configure Playwright to use invalid SMTP credentials via environment variables before triggering an email flow (e.g., password reset).
   • Steps: Trigger the password reset flow.
   • Verification:
     • Assert that the application does not crash or show a generic server error page (like a 500 error).
     • Assert that a user-friendly error message is displayed on the UI (e.g., "Something went wrong. Please try again later.").
     • Assert that no email is sent.

3. Playwright Implementation Instructions

• Email Catching Service:

  • Assume the test environment is configured to use a mock SMTP server like MailHog, which exposes an API to check received emails. The default MailHog API is typically at http://localhost:8025.
  • Create a utility helper function, getEmails(recipient?: string), that fetches messages from the MailHog API (/api/v2/messages). It should be able to filter emails by recipient.
  • Create another helper, clearEmails(), that sends a DELETE request to /api/v1/messages to ensure a clean state before each test. Use this in a test.beforeEach block.

  // e2e/utils/mailhog.helper.ts
  import { APIRequestContext } from '@playwright/test';
  
  const mailhogUrl = process.env.MAILHOG_URL || 'http://localhost:8025';
  
  export async function getEmails(request: APIRequestContext, recipient?: string) {
    const response = await request.get(`${mailhogUrl}/api/v2/messages`);
    const data = await response.json();
    if (recipient) {
      return data.items.filter(email => 
        email.Content.Headers.To.includes(recipient)
      );
    }
    return data.items;
  }
  
  export async function clearEmails(request: APIRequestContext) {
    await request.delete(`${mailhogUrl}/api/v1/messages`);
  }

• Selectors: Use user-facing locators for resilience. Do not use auto-generated IDs or CSS classes.

  • page.getByRole('button', { name: /Sign Up/i })
  • page.getByLabel('Email')
  • page.getByPlaceholder('Enter your full name')

• Assertions:

  • Use expect(page.getByText('...')).toBeVisible() for UI feedback.
  • For email verification, use the MailHog helper:

    test('should send a welcome email on user registration', async ({ page, request }) => {
        // ... registration steps
        const recipientEmail = '[email protected]';
        
        await expect(async () => {
          const emails = await getEmails(request, recipientEmail);
          expect(emails.length).toBe(1);
        }).toPass();
    
        const emails = await getEmails(request, recipientEmail);
        expect(emails[0].Content.Headers.Subject[0]).toBe("Welcome to Giselle's Studio!");
        expect(emails[0].Content.Body).toContain('Welcome to the studio');
    });

4. MCP Integration Guidelines

• Environment Configuration:
  • Ensure the Playwright project is configured to load a .env file.
  • The .env file for the test environment should contain variables to point the application to the mock MailHog server:

    SMTP_HOST=localhost
    SMTP_PORT=1025
    SMTP_USER=
    SMTP_PASS=
    # For testing failure cases, we'll override these in the test itself.

• Execution Command: Structure the command to run these specific tests.

  # Example command to run the new test file
  mcp playwright test --project=chromium --config=./apps/studio.giselles.ai/playwright.config.ts e2e/email-functionality.spec.ts

5. CI-Ready Code Requirements

• Test Organization:

  • Place all tests in the new e2e/email-functionality.spec.ts file.
  • Use test.describe('Email Functionality', () => { ... }) to group the tests.
  • Use test.beforeEach to clear the mailbox and test.afterEach for any other necessary cleanup.

• Independence & Parallelization:

  • Ensure each test is fully independent. Generate unique email addresses for each test run to prevent collisions. Example: const email = \test-user-${Date.now()}@example.com`;`.

• Naming Conventions:

  • Use descriptive test names that clearly state the intent, like test('should send a password reset link to an existing user').

• Error Handling:

  • Use Playwright's built-in retry-ability for assertions, especially for asynchronous operations like checking for emails (expect.toPass()). This makes tests more robust against minor timing issues.
    ```