Testing AI-Generated Node.js Code with Real Dependencies using Docker and Test containers

AI coding tools are becoming part of everyday software development. They can generate API routes, database queries, validation logic, repository classes, test cases, and even Dockerfiles in seconds. That speed is useful, but it also creates a new kind of risk. The generated code may look correct, pass a few mocked tests, and still fail when it meets a real database, a real cache, a real message queue, or a real browser workflow.

This is where many teams start feeling the weakness of mock-heavy testing. Mocks are fast, but they often test our assumptions instead of the actual behavior of the system. A mocked PostgreSQL client will return exactly what we tell it to return. It will not surprise us with a unique constraint violation, a transaction rollback issue, a timestamp behavior difference, a case-sensitive query problem, or a connection pooling edge case. Real systems behave with more friction, and good integration tests should include some of that friction.

Test containers helps solve this problem by starting real dependencies in Docker containers during test execution. Instead of mocking PostgreSQL, Redis, MongoDB, LocalStack, or another service, your test can start a short-lived container, connect your Node.js application to it, run the test, and clean everything up afterward. The Node.js implementation of test containers is designed for this kind of workflow, and the project describes it as a way to run lightweight, throwaway instances of common databases, Selenium browsers, or anything else that can run in Docker.

The idea is simple, but the impact is significant. When AI generates or modifies backend code, test containers gives you a safer way to verify whether that code works against real infrastructure behavior. It does not replace unit tests, and it does not remove the need for code review. Instead, it adds a confidence layer between “the code looks fine” and “this is safe enough to merge.”

Here is the testing flow in one view.

A typical mocked test might look clean, but it can hide important behavior.

describe("createUser", () => {
  it("creates a user and returns an id", async () => {
    const db = {
      query: vi.fn().mockResolvedValue({
        rows: [{ id: 1 }]
      })
    };

    const result = await createUser(db, {
      email: "demo@example.com",
      passwordHash: "hashed-password"
    });

    expect(result.id).toBe(1);
  });
});

This test is useful for checking that your function handles a successful response, but it does not prove that your SQL works. It does not verify that the users table exists, that the email column has a unique constraint, that the query returns the shape you expect, or that PostgreSQL handles your data types the way your mock suggests. If an AI assistant generated the SQL, this test may give you false confidence.

A better integration test uses a real PostgreSQL container.

import { PostgreSqlContainer, StartedPostgreSqlContainer } from "@testcontainers/postgresql";
import { Client } from "pg";
import { afterAll, beforeAll, describe, expect, it } from "vitest";

async function createUser(
  client: Client,
  input: { email: string; passwordHash: string }
): Promise<{ id: number; email: string }> {
  const result = await client.query(
    `
      INSERT INTO users (email, password_hash)
      VALUES ($1, $2)
      RETURNING id, email
    `,
    [input.email, input.passwordHash]
  );

  return result.rows[0];
}

describe("createUser integration test", () => {
  let container: StartedPostgreSqlContainer;
  let client: Client;

  beforeAll(async () => {
    container = await new PostgreSqlContainer("postgres:16-alpine")
      .withDatabase("app_test")
      .withUsername("test_user")
      .withPassword("test_password")
      .start();

    client = new Client({
      host: container.getHost(),
      port: container.getPort(),
      database: container.getDatabase(),
      user: container.getUsername(),
      password: container.getPassword()
    });

    await client.connect();

    await client.query(`
      CREATE TABLE users (
        id SERIAL PRIMARY KEY,
        email VARCHAR(255) UNIQUE NOT NULL,
        password_hash VARCHAR(255) NOT NULL,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
      )
    `);
  }, 60_000);

  afterAll(async () => {
    await client.end();
    await container.stop();
  });

  it("creates a user and returns the generated id", async () => {
    const user = await createUser(client, {
      email: "demo@example.com",
      passwordHash: "hashed-password"
    });

    expect(user.id).toBeGreaterThan(0);
    expect(user.email).toBe("demo@example.com");
  });

  it("fails when the email already exists", async () => {
    await createUser(client, {
      email: "duplicate@example.com",
      passwordHash: "first-password"
    });

    await expect(
      createUser(client, {
        email: "duplicate@example.com",
        passwordHash: "second-password"
      })
    ).rejects.toThrow(/duplicate key value violates unique constraint/i);
  });
});

This test does something the mock cannot do. It proves that the table definition, SQL statement, unique constraint, PostgreSQL behavior, and TypeScript application code work together. That matters even more when some of the code was generated or refactored by an AI tool.

The same idea applies to API-level testing. Instead of testing only the repository function, you can test an Express route connected to the real database.

import express from "express";
import request from "supertest";
import { Pool } from "pg";
import { PostgreSqlContainer, StartedPostgreSqlContainer } from "@testcontainers/postgresql";
import { afterAll, beforeAll, describe, expect, it } from "vitest";

function createApp(pool: Pool) {
  const app = express();
  app.use(express.json());

  app.post("/users", async (req, res) => {
    const { email, password } = req.body;

    if (!email || !password) {
      return res.status(400).json({ error: "Email and password are required" });
    }

    try {
      const existingUser = await pool.query(
        "SELECT id FROM users WHERE email = $1",
        [email]
      );

      if (existingUser.rowCount > 0) {
        return res.status(409).json({ error: "Email already registered" });
      }

      const result = await pool.query(
        `
          INSERT INTO users (email, password_hash)
          VALUES ($1, $2)
          RETURNING id, email
        `,
        [email, `hashed-${password}`]
      );

      return res.status(201).json(result.rows[0]);
    } catch {
      return res.status(500).json({ error: "Internal server error" });
    }
  });

  return app;
}

describe("POST /users", () => {
  let container: StartedPostgreSqlContainer;
  let pool: Pool;
  let app: ReturnType<typeof createApp>;

  beforeAll(async () => {
    container = await new PostgreSqlContainer("postgres:16-alpine").start();

    pool = new Pool({
      host: container.getHost(),
      port: container.getPort(),
      database: container.getDatabase(),
      user: container.getUsername(),
      password: container.getPassword()
    });

    await pool.query(`
      CREATE TABLE users (
        id SERIAL PRIMARY KEY,
        email VARCHAR(255) UNIQUE NOT NULL,
        password_hash VARCHAR(255) NOT NULL,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
      )
    `);

    app = createApp(pool);
  }, 60_000);

  afterAll(async () => {
    await pool.end();
    await container.stop();
  });

  it("registers a new user", async () => {
    const response = await request(app)
      .post("/users")
      .send({
        email: "new-user@example.com",
        password: "secure-password"
      })
      .expect(201);

    expect(response.body.id).toBeDefined();
    expect(response.body.email).toBe("new-user@example.com");
  });

  it("returns conflict for duplicate email", async () => {
    await request(app)
      .post("/users")
      .send({
        email: "same-user@example.com",
        password: "first-password"
      })
      .expect(201);

    const response = await request(app)
      .post("/users")
      .send({
        email: "same-user@example.com",
        password: "second-password"
      })
      .expect(409);

    expect(response.body.error).toBe("Email already registered");
  });
});

This is a more realistic safety check for AI-generated backend code. If an assistant changes the route, modifies the SQL query, renames a column, removes the duplicate check, or mishandles an error path, this test has a much better chance of catching the issue than a mock-based test.

Testcontainers also works well with browser testing. Cypress and Playwright are often used to test the full user experience, but those tests are only as reliable as the environment behind them. Cypress maintains Docker images with the required dependencies for running Cypress in Docker, and its CI documentation covers Docker images, caching, parallel execution, and environment configuration. Playwright also provides Docker guidance, including images that contain browser system dependencies for running tests in containerized environments.

A useful pattern is to let Testcontainers provide the backend dependency while Playwright or Cypress validates the user flow. For example, a registration flow can use a real PostgreSQL container, a real API server, and a real browser test. This gives you confidence that the user interface, HTTP layer, validation logic, database query, and persistence behavior all work together.

import { test, expect } from "@playwright/test";
import { PostgreSqlContainer, StartedPostgreSqlContainer } from "@testcontainers/postgresql";

let container: StartedPostgreSqlContainer;
let baseUrl: string;

test.beforeAll(async () => {
  container = await new PostgreSqlContainer("postgres:16-alpine").start();

  baseUrl = await startApplicationForTests({
    database: {
      host: container.getHost(),
      port: container.getPort(),
      name: container.getDatabase(),
      user: container.getUsername(),
      password: container.getPassword()
    }
  });
});

test.afterAll(async () => {
  await stopApplicationForTests();
  await container.stop();
});

test("a user can register and see the profile page", async ({ page }) => {
  await page.goto(`${baseUrl}/register`);
  await page.fill("[name='email']", "playwright-user@example.com");
  await page.fill("[name='password']", "secure-password");
  await page.click("button[type='submit']");

  await expect(page.locator("[data-testid='profile-email']")).toHaveText(
    "playwright-user@example.com"
  );
});

The startApplicationForTests function depends on your project structure, but the principle is straightforward. Start the dependency first, pass its runtime connection details into the app, then run the browser test against the real stack.

This pattern is especially valuable when AI coding tools are changing frontend and backend code together. A generated form update may look correct in the browser, but it might send a payload that no longer matches the API. A generated API route may compile, but it might break database constraints. A generated repository method may pass unit tests, but fail against PostgreSQL because of an incorrect column name. Real dependency testing helps catch these integration gaps.

Test containers is not only for PostgreSQL. The Node.js ecosystem has modules for databases and services such as MongoDB, Redis, and LocalStack, and it also supports generic containers for custom services. The official getting started guide demonstrates using PostgreSQL for Node.js tests, while the broader project describes test containers as a way to test with the same kinds of services used in production instead of relying on mocks or in-memory replacements.

import { GenericContainer, Wait } from "testcontainers";

const service = await new GenericContainer("my-company/search-service:test")
  .withExposedPorts(8080)
  .withEnvironment({
    NODE_ENV: "test"
  })
  .withWaitStrategy(Wait.forHttp("/health", 8080))
  .start();

const searchServiceUrl = `http://${service.getHost()}:${service.getMappedPort(8080)}`;

Readiness checks are important. A container being “started” does not always mean the service inside it is ready to accept requests. Waiting for an HTTP endpoint, a log message, or a health check can prevent flaky tests that fail only because the test ran too early.

There are trade-offs. Test containers-based tests are slower than unit tests. A PostgreSQL container may take a few seconds to start, especially on the first run when Docker needs to pull the image. These tests also require Docker to be available locally and in CI. That is why test containers should not replace your unit test suite. The best approach is layered testing. Keep fast unit tests for pure functions and isolated business logic. Use test containers for integration points where real dependency behavior matters.

In practice, you can keep performance reasonable by starting containers once per test file, cleaning data between tests, and avoiding unnecessary container restarts. You can truncate tables, use transactions, or create isolated schemas depending on your application. Recent test containers Node releases also continue to improve operational behavior. The 11.14.0 release added auto cleanup control for containers and compose environments, along with support for running in parallel for distinct UIDs.

A simple GitHub Actions setup is usually enough because hosted Ubuntu runners already support Docker.

name: Integration Tests

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      - name: Run unit and integration tests
        run: npm test

The main requirement is that your CI environment can run Docker containers. Once that is available, your tests can create real dependencies on demand without maintaining long-lived shared test databases.

The most important mindset shift is this: mocks are not bad, but they are not enough. They are great for speed, edge cases, and isolated logic. They are weak when the risk lives in the contract between your application and a real dependency. AI-generated code increases that risk because it can produce code that looks reasonable while subtly misunderstanding the database schema, query behavior, or runtime environment.

Test containers gives TypeScript teams a practical way to validate those boundaries. It lets you test Node.js APIs against real databases, run browser flows against realistic backends, verify migrations, check queue or cache behavior, and build more trustworthy CI pipelines. For teams adopting AI-assisted development, that confidence layer becomes even more valuable.

The goal is not to test everything with Docker. The goal is to stop pretending that a mock database proves your application works with a real one. Start with one important flow, such as registration, checkout, booking, authentication, or report generation. Replace the mock-heavy integration test with a test containers-backed test. Run it locally. Add it to CI. Then expand only where the added confidence is worth the extra runtime.

As AI tools make code generation faster, our validation systems need to become more grounded. Test containers is one of the most practical ways to bring that grounding into a modern TypeScript and Node.js workflow.

推荐订阅源

DEV Community