Chapter 16: SAAS Testing Strategy and Quality Assurance

In Chapter 14, we established a CI/CD pipeline that acts as the "gatekeeper" for our SAAS application. In Chapter 15, we used Biome (Linter) to ensure the "static quality" of our code. However, a gatekeeper that only checks syntax is far from enough. Our CI process also includes a pnpm test command—this is the core of quality assurance.

The "dynamic quality" of code—whether it works as expected at runtime—must be guaranteed through automated testing.

For developers migrating from the Python stack (especially Django), you're likely very familiar with pytest and unittest.TestCase, as well as Django's powerful test client (self.client.get('/my-url/')) and ORM-level test database isolation.

In the Next.js/React full-stack ecosystem, testing philosophy is similar, but tools and layered strategies differ. We'll adopt a strategy that mixes the "testing pyramid" and "testing trophy," ensuring coverage from the smallest logic units to the most complex purchase flows.

In this chapter, we'll configure and practice four key types of testing:

1. Unit Testing (Vitest): For pure, isolated business logic.
2. Component Testing (RTL): For standalone React components.
3. E2E Testing (Playwright): For critical, cross-front-end/back-end user journeys.
4. Database Testing (pgTAP): For ensuring data layer integrity.

16.1. Unit Testing (Vitest)

What is Unit Testing? Unit tests are at the bottom of the pyramid. They test a single "unit"—typically an isolated function or module, completely detached from React, Next.js, or even databases. They must be fast, very fast.

Why Vitest? In the past, Jest was the king of Node.js testing. But just as Biome replaced ESLint+Prettier, Vitest is becoming the new standard with its speed and modern features (based on Vite, built-in ESM/TS support).

• Extremely Fast: Leverages modern JavaScript features, on-demand compilation, and smart caching.
• API Compatible: It provides a nearly 1:1 API compatible with Jest (describe, it, expect, vi.mock), making migration extremely low-cost.
• Simple Configuration: Out-of-the-box support for TypeScript and JSX.

[Code Analysis]: Testing a Credit Calculation Helper Function

Assume we have a simple helper function in src/lib/credit-utils.ts:

// src/lib/credit-utils.ts
export function calculateCreditsForPlan(planId: 'free' | 'pro' | 'lifetime'): number {
  if (planId === 'pro') return 1000;
  if (planId === 'lifetime') return 50000;
  return 10;
}

Our Vitest test file src/lib/credit-utils.test.ts would look like this:

// src/lib/credit-utils.test.ts
import { describe, it, expect } from 'vitest';
import { calculateCreditsForPlan } from './credit-utils';

// 'describe' defines a test suite
describe('Credit Calculation Utilities', () => {

  // 'it' or 'test' defines a single test case
  it('should return 1000 credits for pro plan', () => {
    // 'expect' is the assertion
    expect(calculateCreditsForPlan('pro')).toBe(1000);
  });

  it('should return 10 credits for free plan', () => {
    expect(calculateCreditsForPlan('free')).toBe(10);
  });

  it('should return 50000 credits for lifetime plan', () => {
    expect(calculateCreditsForPlan('lifetime')).toBe(50000);
  });

});

This test runs in a Node.js environment and is lightning-fast, perfectly ensuring the correctness of our core business logic.

16.2. Component Testing (React Testing Library)

What is Component Testing? It sits in the middle of the pyramid, testing React component rendering and interaction. We no longer care about the internal logic of calculateCreditsForPlan function; we only care about "when the user clicks the button, does the UI update correctly?"

React Testing Library (RTL) is the absolute standard in this field (integrated by default in Next.js). RTL's core philosophy is: "The more your tests resemble the way your software is used, the more confidence they can give you."

RTL won't let you check the component's internal state or props. Instead, it forces you to:

1. Render: Render the component.
2. Find: Find elements like a user (e.g., by text getByText('Subscribe') or form label getByLabelText('Email')).
3. Act: Interact with elements like a user (e.g., fireEvent.click(button)).
4. Assert: Assert that the UI changed as expected (e.g., expect(getByText('Success!')).toBeInTheDocument()).

[Code Analysis]: Testing the NewsletterForm Component

Recall the NewsletterForm from Chapter 13. We'll test that it correctly displays an error when the user enters an invalid email.

// src/components/forms/NewsletterForm.test.tsx
import { render, screen, fireEvent } from '@testing-library/react';
import { describe, it, expect, vi } from 'vitest';
import { NewsletterForm } from './NewsletterForm';

// Mock Server Action
// We don't want to actually call the Resend API in tests
vi.mock('@/actions/newsletter.actions', () => ({
  subscribeToNewsletter: vi.fn(),
}));
import { subscribeToNewsletter } from '@/actions/newsletter.actions';

describe('NewsletterForm', () => {
  it('should render the form', () => {
    render(<NewsletterForm />);

    // Check that form and button are rendered
    expect(screen.getByPlaceholderText('your@email.com')).toBeInTheDocument();
    expect(screen.getByRole('button', { name: /Subscribe/i })).toBeInTheDocument();
  });

  it('should show an error message for an invalid email', async () => {
    // Mock Server Action to return an error
    (subscribeToNewsletter as vi.Mock).mockResolvedValueOnce({
      error: 'Invalid email.',
    });

    render(<NewsletterForm />);

    const input = screen.getByPlaceholderText('your@email.com');
    const button = screen.getByRole('button', { name: /Subscribe/i });

    // Simulate user input
    await fireEvent.change(input, { target: { value: 'not-an-email' } });
    // Simulate user click
    await fireEvent.click(button);

    // Wait and assert error message appears
    // 'findByText' is the async version of 'getByText', waits for UI update
    expect(await screen.findByText('Invalid email.')).toBeInTheDocument();
  });
});

This test perfectly simulates the component's internal interaction and uses vi.mock to isolate external dependencies (Server Action).

16.3. E2E Testing (Playwright): Simulating User Purchase

What is E2E Testing? End-to-End (E2E) tests are at the top of the pyramid. They don't care about any code implementation, only the complete user journey. E2E tests are your ultimate "acceptance criteria."

We'll use Playwright (developed by Microsoft), the current benchmark for E2E testing. It launches a real browser (Chromium, Firefox, WebKit), opens your website (on a test server), then clicks, scrolls, and types like a real person.

[Code Analysis]: Simulating the Complete Flow of User Purchasing a Subscription

This is the most important test case in our SAAS application. If it passes, you know your core payment flow is intact.

Strategy: We can't actually charge a credit card in tests. We must Mock Stripe. But we're not just mocking JS functions; we're mocking network requests. Playwright allows us to intercept all requests made by the browser.

1. When the browser tries to access checkout.stripe.com, we intercept it.
2. Instead of actually visiting Stripe, we immediately redirect it back to our success_url.
3. At the same time, our test script needs a way to "pretend" the Stripe Webhook has been delivered. The most reliable method is for the test script to directly manipulate the test database, setting the user's status to "Pro".

// tests/e2e/subscription.spec.ts
import { test, expect } from '@playwright/test';
import { db } from '@/db'; // Assume E2E tests can access the database
import { users } from '@/db/schema';
import { eq } from 'drizzle-orm';

const TEST_USER_EMAIL = `test-user-${Date.now()}@example.com`;
const TEST_USER_PASSWORD = 'Password123';

test.describe('Subscription Flow', () => {

  // Before each test case runs, reset database state
  test.beforeEach(async () => {
    // 1. Cleanup: ensure test user doesn't exist
    await db.delete(users).where(eq(users.email, TEST_USER_EMAIL));
  });

  test('A new user can register, purchase a Pro plan, and see their credits', async ({ page }) => {

    // Step 1: Register
    await page.goto('/register');
    await page.getByLabel('Email').fill(TEST_USER_EMAIL);
    await page.getByLabel('Password').fill(TEST_USER_PASSWORD);
    await page.getByRole('button', { name: 'Register' }).click();

    // Should redirect to dashboard
    await expect(page.getByText('Welcome')).toBeVisible();

    // Step 2: Navigate to pricing page
    await page.getByRole('link', { name: 'Pricing' }).click();
    await expect(page.getByText('Pro Plan')).toBeVisible();

    // Step 3: Intercept Stripe Checkout
    await page.route('**/api/stripe/checkout', (route) => {
      // (This is simplified mocking, actually you might intercept the createCheckoutSession Server Action)
      // Assume clicking button calls an API or Action, we intercept it
      // Simpler method is to intercept the *external* call to Stripe
      console.log('Intercepted Stripe checkout request');
    });

    // Step 4: Click upgrade button (from Pro Plan card)
    // Assume card is in `[data-testid="plan-pro"]`
    await page.locator('[data-testid="plan-pro"] button').click();

    // --- Critical Mock Flow ---
    // In a real E2E test, clicking would redirect to Stripe.
    // We'll "cheat" here and simulate successful payment.

    // Mock 1: Webhook handler is triggered
    // E2E test directly updates database, pretending Webhook completed
    const testUser = await db.query.users.findFirst({ where: eq(users.email, TEST_USER_EMAIL) });

    // Pretend Stripe Webhook succeeded and granted credits
    await db.update(users)
      .set({
        subscriptionStatus: 'pro',
        totalCredits: 1000 // (from price-config)
      })
      .where(eq(users.id, testUser!.id));

    // Mock 2: User is redirected back to success page
    await page.goto('/dashboard?payment=success');

    // Step 5: Verify results
    // Refresh page to get latest server-rendered data
    await page.reload();

    // Assert: User is now on Pro plan
    await expect(page.getByText('Plan: Pro')).toBeVisible();
    // Assert: User received credits
    await expect(page.getByText(/Credits: 1000/i)).toBeVisible();
  });
});

This test is expensive and slow (may take 10-30 seconds), but the confidence it provides is unparalleled.

16.4. Drizzle Database Testing (pgTAP)

The last layer, and the deepest: the data itself. Our application logic relies on database constraints:

• users.email must be unique (UNIQUE).
• creditTransactions.amount cannot be NULL.
• users.totalCredits must be >= 0 (CHECK constraint).

How do we test these database-internal rules?

The answer is pgTAP, a testing framework for PostgreSQL. It allows you to... write tests in SQL!

This might be novel for Python developers, as Django/Flask developers typically test these at the application layer (e.g., catching IntegrityError). pgTAP lets us verify immediately after database migrations (Chapter 10) that the database structure meets expectations.

[Code Analysis]: Testing SQL with SQL

pgTAP tests are typically stored in the db/tests/ directory and run by the pnpm test:db script.

-- db/tests/test_schema.sql
BEGIN;
-- Load pgTAP extension
CREATE EXTENSION IF NOT EXISTS pgtap;

-- Start testing
SELECT plan(3); -- Declare we have 3 tests

-- Test 1: Check if 'users' table exists
SELECT has_table('public', 'users', 'Table "users" should exist.');

-- Test 2: Check if 'users' table has 'total_credits' column
SELECT has_col('public', 'users', 'total_credits', 'Column "users.total_credits" should exist.');

-- Test 3: Check if CHECK constraint for 'total_credits' is valid
-- Try to insert illegal data (credits < 0)
-- 'throws_ok' expects this operation to fail
SELECT throws_ok(
  $$
    INSERT INTO users (id, email, total_credits)
    VALUES ('test-id', 'check-test@example.com', -50)
  $$,
  '23514', -- 23514 is the error code for check_violation in PostgreSQL
  'CHECK constraint for total_credits >= 0 should be active.'
);

-- Finish testing
SELECT * FROM finish();
ROLLBACK;

This test runs entirely within PostgreSQL, providing the final line of defense for our data integrity.

Chapter 16 Summary

In this chapter, we built a comprehensive, multi-layered quality assurance system for our SAAS application, perfectly complementing the CI/CD pipeline from Chapter 14.

• Unit Testing (Vitest): We used Vitest to quickly test isolated, pure business logic (like helper functions). This is the pyramid's foundation, ensuring the correctness of basic modules.
• Component Testing (RTL): We used React Testing Library to simulate user interactions with React components. We verified UI rendering and state transitions without caring about component internals.
• E2E Testing (Playwright): We implemented the "crown jewel"—an end-to-end test simulating the complete payment flow from user registration to subscription purchase. By intercepting network requests and directly manipulating the test database, we verified the core value of our entire SAAS system.
• Database Testing (pgTAP): We dove into the database layer, using pgTAP to write SQL tests ensuring our Schema constraints (like CHECK constraints) work as expected, guaranteeing ultimate data integrity.

Now, when our GitHub Action runs pnpm test, it's no longer an empty command. It's a powerful guardian that reviews our code from four different dimensions, ensuring only high-quality, functionally correct code gets deployed to production.