LocalStack vs Testcontainers AWS Integration Tests (2026)

TL;DR

LocalStack and Testcontainers are complementary, not direct substitutes. LocalStack supplies the AWS-compatible services; Testcontainers gives a JUnit suite an isolated LocalStack lifecycle. Choose Docker Compose for a shared developer stack, choose Testcontainers plus LocalStack for repeatable automated tests, and retain a narrow real-AWS validation stage.

Key Takeaways

• LocalStack emulates AWS APIs, while Testcontainers starts and stops dependencies around a test suite.
• Use Testcontainers with the LocalStack image when each suite needs an isolated, randomly mapped endpoint.
• Use Docker Compose when several processes or developers intentionally share one long-lived local stack.
• Route AWS SDK v2 clients through an explicit endpoint, test credentials, region, and S3 path-style access.
• Pin Testcontainers and LocalStack versions, and provide the required LocalStack authentication token through secrets.
• Keep a smaller real-AWS test stage because local emulation cannot prove IAM, quotas, networking, or exact managed-service behavior.

For localstack vs testcontainers aws integration tests, the practical answer is usually both: LocalStack emulates AWS APIs, while Testcontainers creates and removes the LocalStack container for a test run. If you compare them as interchangeable products, you miss the lifecycle decision that determines isolation, endpoint discovery, cleanup, and CI reliability.

This guide builds the same S3 and SQS round trip twice in Java. First, you point JUnit at a shared LocalStack started by Docker Compose. Then you let Testcontainers start a private LocalStack on a random host port. The result gives you evidence for choosing a team workflow, not a feature checklist. For broader test-boundary design, start with the integration testing guide.

TL;DR

LocalStack answers, "Which AWS-like service handles this SDK call?" Testcontainers answers, "Who starts the dependency, finds its port, waits for readiness, and removes it?" Testcontainers does not independently reproduce S3, SQS, Lambda, or IAM. Its LocalStack module runs a LocalStack image.

Verdict: default to Testcontainers managing a pinned LocalStack image for automated Java tests. Keep Compose when humans need a stable endpoint across application restarts. Run a focused suite against real AWS before release because neither local model proves IAM policy evaluation, service quotas, VPC behavior, eventual consistency, or complete AWS parity.

What You Will Build

You will create:

• One Maven project using Java 21, JUnit, AWS SDK for Java 2.x, and Testcontainers.
• Reusable S3 and SQS client factories with explicit local endpoints.
• One integration test against LocalStack on fixed port 4566.
• The same assertions against a suite-owned LocalStack container on a random port.
• A GitHub Actions job that exercises both lifecycle models without storing AWS keys.

The examples use S3 and SQS because they expose useful differences: S3 needs careful endpoint addressing, while SQS returns an endpoint-specific queue URL. The pattern extends to other supported services after you validate their behavior.

Prerequisites

Install Java 21 LTS, Maven 3.9 or newer, Docker Engine 27 or a compatible current Docker Desktop, and Docker Compose v2. Use Testcontainers Java 2.0.5, AWS SDK for Java 2.48.1, JUnit 6.1.2, and the LocalStack 2026.7 image in this reproducible example. Pin versions in production and review upgrades intentionally.

LocalStack images require authentication from March 23, 2026. Create a LocalStack account token, export it locally, and store it as a masked CI secret. It is a product token, not an AWS access key. The test SDK clients still use LocalStack's conventional test credentials.

export LOCALSTACK_AUTH_TOKEN=replace-with-your-token
java -version
mvn -version
docker version
docker compose version
test -n "${LOCALSTACK_AUTH_TOKEN:-}"

All five commands must exit successfully. If Docker is unfamiliar, work through Docker basics for testers before debugging Java code.

How localstack vs testcontainers aws integration tests differ

LocalStack is the system under test for these examples. It accepts signed AWS SDK requests at a local gateway and implements service behavior for S3, SQS, and many other AWS APIs. You evaluate its coverage service by service and operation by operation. A passing PutObject test says nothing about an untested S3 Object Lock, IAM condition, or cross-region path.

Testcontainers is test infrastructure code. The JUnit extension observes @Container, starts Docker resources before tests, exposes mapped connection details, and stops resources afterward. The LocalStack module also supplies convenient methods such as getEndpoint(), getAccessKey(), getSecretKey(), and getRegion(). It does not increase LocalStack's AWS fidelity.

Therefore the useful comparison is shared versus test-owned lifecycle. Compose gives your application, test runner, and manual AWS CLI commands a predictable port. Testcontainers gives each suite ownership and reduces state leakage. Read Testcontainers for integration tests for the general container pattern, and use the implementation below to see how the AWS-specific pieces fit.

Step 1: Create the Maven Test Project

Create an empty directory and add this pom.xml. The three BOMs align each dependency family, while Surefire runs classes ending in Test. Testcontainers 2.x renamed modules with a testcontainers- prefix and moved the LocalStack class to org.testcontainers.localstack. Old 1.x imports copied from earlier tutorials will not compile here.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>aws-integration-tests</artifactId>
  <version>1.0.0</version>
  <properties>
    <maven.compiler.release>21</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>bom</artifactId>
        <version>2.48.1</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.junit</groupId>
        <artifactId>junit-bom</artifactId>
        <version>6.1.2</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.testcontainers</groupId>
        <artifactId>testcontainers-bom</artifactId>
        <version>2.0.5</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>s3</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>sqs</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>testcontainers-junit-jupiter</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>testcontainers-localstack</artifactId>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.14.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.5</version>
      </plugin>
    </plugins>
  </build>
</project>

Create src/test/java/example.

Verify: Run mvn -q -DskipTests test. Maven should resolve the dependencies and finish with exit code 0. A missing artifact usually means a mistyped 2.x module name or a repository proxy that has not synchronized the pinned release.

Step 2: Build Endpoint-Aware AWS Clients and Assertions

Create src/test/java/example/AwsClients.java. Always set four local-test inputs explicitly: endpoint, region, access key, and secret key. AWS SDK v2 still needs a region when an endpoint is overridden because it signs requests with that region. Force path-style S3 access so bucket names remain in the URL path instead of being prefixed to a local host name.

package example;

import java.net.URI;
import software.amazon.awssdk.auth.credentials.AwsBasicCredentials;
import software.amazon.awssdk.auth.credentials.StaticCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.sqs.SqsClient;

final class AwsClients {
  private AwsClients() {}

  static S3Client s3(URI endpoint, String region, String key, String secret) {
    return S3Client.builder()
        .endpointOverride(endpoint)
        .region(Region.of(region))
        .credentialsProvider(credentials(key, secret))
        .forcePathStyle(true)
        .build();
  }

  static SqsClient sqs(URI endpoint, String region, String key, String secret) {
    return SqsClient.builder()
        .endpointOverride(endpoint)
        .region(Region.of(region))
        .credentialsProvider(credentials(key, secret))
        .build();
  }

  private static StaticCredentialsProvider credentials(String key, String secret) {
    return StaticCredentialsProvider.create(AwsBasicCredentials.create(key, secret));
  }
}

Next create src/test/java/example/AwsRoundTrip.java. Unique names make parallel runs safe. The finally block removes both resources even when an assertion fails, which matters for the long-lived Compose stack.

package example;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;

import java.util.UUID;
import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.sqs.SqsClient;

final class AwsRoundTrip {
  private AwsRoundTrip() {}

  static void verify(S3Client s3, SqsClient sqs) {
    String suffix = UUID.randomUUID().toString().replace("-", "").substring(0, 12);
    String bucket = "orders-it-" + suffix;
    String key = "events/order-created.json";
    String payload = "{\"orderId\":\"A-1042\"}";
    var queueUrl = new java.util.concurrent.atomic.AtomicReference<String>();
    boolean bucketCreated = false;

    try {
      s3.createBucket(b -> b.bucket(bucket));
      bucketCreated = true;
      s3.putObject(b -> b.bucket(bucket).key(key), RequestBody.fromString(payload));
      String stored = s3.getObjectAsBytes(b -> b.bucket(bucket).key(key)).asUtf8String();
      assertEquals(payload, stored);

      queueUrl.set(sqs.createQueue(b -> b.queueName("orders-" + suffix)).queueUrl());
      sqs.sendMessage(b -> b.queueUrl(queueUrl.get()).messageBody(payload));
      var messages = sqs.receiveMessage(b -> b.queueUrl(queueUrl.get())
          .waitTimeSeconds(1).maxNumberOfMessages(10)).messages();
      assertTrue(messages.stream().anyMatch(message -> payload.equals(message.body())));
    } finally {
      if (queueUrl.get() != null) {
        sqs.deleteQueue(b -> b.queueUrl(queueUrl.get()));
      }
      if (bucketCreated) {
        s3.deleteObject(b -> b.bucket(bucket).key(key));
        s3.deleteBucket(b -> b.bucket(bucket));
      }
    }
  }
}

This helper tests behavior, not merely container health: write and read an S3 object, enqueue and receive an SQS message, assert payload equality, then clean up.

Verify: Run mvn -q -DskipTests test again. Both utility classes should compile. If Java reports that a lambda captures a non-final variable, ensure the downloaded example matches the code above and that Maven is compiling with release 21.

Step 3: Run the Test Against Shared LocalStack

Add compose.yaml at the project root. This model exposes a fixed loopback port and keeps LocalStack alive across test commands. It is convenient when a developer starts an application, runs tests from an IDE, and inspects resources with the AWS CLI.

services:
  localstack:
    image: localstack/localstack:2026.7
    ports:
      - "127.0.0.1:4566:4566"
    environment:
      LOCALSTACK_AUTH_TOKEN: ${LOCALSTACK_AUTH_TOKEN:?set LOCALSTACK_AUTH_TOKEN}
      SERVICES: s3,sqs
      DEBUG: "0"
    healthcheck:
      test: ["CMD-SHELL", "curl -fsS http://localhost:4566/_localstack/health >/dev/null || exit 1"]
      interval: 2s
      timeout: 2s
      retries: 30

Create src/test/java/example/SharedLocalStackTest.java:

package example;

import java.net.URI;
import org.junit.jupiter.api.Test;

class SharedLocalStackTest {
  @Test
  void storesAnObjectAndDeliversAQueueMessage() {
    URI endpoint = URI.create(System.getProperty("aws.endpoint", "http://localhost:4566"));
    try (var s3 = AwsClients.s3(endpoint, "us-east-1", "test", "test");
         var sqs = AwsClients.sqs(endpoint, "us-east-1", "test", "test")) {
      AwsRoundTrip.verify(s3, sqs);
    }
  }
}

Start the service only after exporting the token. Compose owns readiness through its health check; a blind sleep either wastes time or flakes on a slow image pull. The test owns its AWS resources but not the container.

docker compose up -d --wait
curl -fsS http://localhost:4566/_localstack/health
mvn -q -Dtest=SharedLocalStackTest test

Verify: The curl response should report LocalStack health, Maven should report one successful test, and docker compose ps should show the service as healthy. Run the test a second time to prove that unique names and cleanup prevent collisions. For larger shared environments, apply the ownership rules in Docker Compose for test environments.

Step 4: Let Testcontainers Own LocalStack

Create src/test/java/example/TestcontainersLocalStackTest.java. The AWS assertions do not change. Only the dependency lifecycle and connection values change. Testcontainers starts the pinned image, waits for readiness, maps gateway port 4566 to an available host port, and exposes the resulting endpoint.

package example;

import static java.util.Objects.requireNonNull;

import org.junit.jupiter.api.Test;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;
import org.testcontainers.localstack.LocalStackContainer;
import org.testcontainers.utility.DockerImageName;

@Testcontainers
class TestcontainersLocalStackTest {
  private static final String AUTH_TOKEN = requireNonNull(
      System.getenv("LOCALSTACK_AUTH_TOKEN"),
      "Set LOCALSTACK_AUTH_TOKEN before running this test");

  @Container
  static final LocalStackContainer LOCALSTACK = new LocalStackContainer(
      DockerImageName.parse("localstack/localstack:2026.7"))
      .withEnv("LOCALSTACK_AUTH_TOKEN", AUTH_TOKEN)
      .withServices("s3", "sqs");

  @Test
  void storesAnObjectAndDeliversAQueueMessage() {
    try (var s3 = AwsClients.s3(LOCALSTACK.getEndpoint(), LOCALSTACK.getRegion(),
             LOCALSTACK.getAccessKey(), LOCALSTACK.getSecretKey());
         var sqs = AwsClients.sqs(LOCALSTACK.getEndpoint(), LOCALSTACK.getRegion(),
             LOCALSTACK.getAccessKey(), LOCALSTACK.getSecretKey())) {
      AwsRoundTrip.verify(s3, sqs);
    }
  }
}

The static field creates one container per test class, not per test method. That usually balances isolation and startup cost. A non-static @Container starts a new instance for each method, which is useful only when the test cannot reliably reset state. Do not call start() manually when the JUnit extension owns the annotated container.

mvn -q -Dtest=TestcontainersLocalStackTest test
docker ps --filter ancestor=localstack/localstack:2026.7

Verify: Maven should pass the same S3 and SQS assertions. After the JVM exits, docker ps should not show the suite's LocalStack container. The lack of a fixed host port is expected and is a primary source of parallel-test safety.

Step 5: Put Both Lifecycle Models in CI

Add .github/workflows/aws-integration.yml. Store LOCALSTACK_AUTH_TOKEN as a repository or organization secret. No AWS key belongs in this job because all SDK traffic targets LocalStack.

name: AWS integration tests
on:
  pull_request:
  workflow_dispatch:

jobs:
  integration:
    runs-on: ubuntu-24.04
    timeout-minutes: 20
    env:
      LOCALSTACK_AUTH_TOKEN: ${{ secrets.LOCALSTACK_AUTH_TOKEN }}
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-java@v5
        with:
          distribution: temurin
          java-version: "21"
          cache: maven
      - name: Start shared LocalStack
        run: docker compose up -d --wait
      - name: Test shared lifecycle
        run: mvn -B -Dtest=SharedLocalStackTest test
      - name: Test suite-owned lifecycle
        run: mvn -B -Dtest=TestcontainersLocalStackTest test
      - name: Print LocalStack logs on failure
        if: failure()
        run: docker compose logs --no-color localstack
      - name: Clean up Compose resources
        if: always()
        run: docker compose down --volumes

This job deliberately demonstrates both models. A normal project should keep only the model it uses, unless the application officially supports an externally supplied endpoint as well as suite-owned tests. Testcontainers talks to the runner's Docker daemon directly, so do not add Docker-in-Docker unless your CI platform specifically requires and documents it.

Verify: Open a pull request and confirm both named Maven steps pass. The cleanup step must run even after a failure, and logs must not print the authentication token. Teams designing their first pipeline can use the DevOps for QA roadmap to place this job among unit, API, browser, and deployment stages.

Step 6: Measure the Lifecycle You Actually Use

Do not copy a benchmark from another laptop. Image cache state, Docker memory, CPU architecture, enabled services, and CI contention dominate startup time. Measure cold startup and warm test execution separately on your runner.

docker compose down --volumes
/usr/bin/time -p docker compose up -d --wait
/usr/bin/time -p mvn -q -Dtest=SharedLocalStackTest test
docker compose down --volumes
/usr/bin/time -p mvn -q -Dtest=TestcontainersLocalStackTest test

Record the real values across several clean CI runs. Also track failed startups, leftover resources, parallel collision rate, and debugging effort. Compose can win an interactive loop because its already-running container avoids repeated startup. Testcontainers often wins operationally because lifecycle code travels with the test and random mappings avoid fixed-port conflicts.

Verify: Every command must exit 0, Compose must have no remaining project containers after down, and the Testcontainers run must remove its container automatically. A faster run that leaks state is not a successful optimization.

When localstack vs testcontainers aws integration tests work together

LocalStack's strongest value is fast, local feedback through real AWS SDK serialization, signing, request routing, and multi-service workflows. You can test that an application stores an event payload in S3 and publishes the same payload to SQS without an AWS account, internet dependency, or per-test cloud cleanup. You can also inspect logs and reproduce failures on a workstation.

Its limit is semantic parity. Service coverage varies, advanced features may require a paid plan, and local networking is not a VPC. IAM policies, KMS key behavior, quotas, regional differences, managed retries, service-side encryption, and eventual consistency can differ from AWS. Treat every emulated assertion as evidence about your application contract, not proof that AWS will behave identically.

Testcontainers contributes hermetic lifecycle, dynamic endpoints, wait strategies, log access, and cleanup. It also composes LocalStack with real containerized dependencies such as PostgreSQL or Kafka in one suite. Its costs are Docker availability, image-pull time, resource consumption, and extra complexity on remote or locked-down runners. It cannot rescue a weak assertion or an unsupported LocalStack API.

The combination is strongest when the test boundary is explicit: LocalStack covers frequent developer and pull request checks, then a small real-AWS stage validates high-risk contracts. That stage should use short-lived CI credentials, unique resource prefixes, strict cleanup, spending limits, and a dedicated account.

Which Should You Choose

Choose Testcontainers plus LocalStack when tests run independently in pull requests, developers need one-command setup, parallel jobs share a runner, or stale state has caused flakes. This is the best default for a Java integration-test suite because the test declares the exact dependency image and discovers its endpoint programmatically.

Choose shared LocalStack through Compose when several processes need one stable environment, a developer wants to inspect state between commands, non-JVM tools share the stack, or startup cost dominates a rapid manual loop. Assign explicit reset and shutdown ownership. A fixed port is convenient until two builds use it simultaneously.

Choose real AWS for IAM authorization, account boundaries, VPC endpoints, quotas, managed encryption, regional behavior, and final infrastructure validation. Keep the suite narrow and valuable rather than duplicating every local assertion. The AWS certification guide for QA engineers helps testers build the service vocabulary needed to identify those cloud-only risks.

Most teams should use a test pyramid inside the integration layer: many LocalStack checks managed by Testcontainers, fewer shared end-to-end environment checks, and a small number of real-AWS release gates.

Common Mistakes

• Calling Testcontainers an AWS emulator: it orchestrates containers. LocalStack, Moto, or a service-specific image supplies emulated behavior. Confusing those roles produces meaningless feature comparisons.
• Using latest: an unreviewed image update can change service behavior overnight. Pin 2026.7 here, then let dependency automation propose upgrades with test evidence.
• Leaving the SDK on default AWS endpoints: test credentials can still trigger confusing provider-chain errors, and real credentials create a serious blast radius. Assert or inject the local endpoint in the test profile.
• Omitting S3 path-style access: virtual-host addressing can turn a bucket into a host prefix that does not resolve consistently across Docker and CI environments.
• Hard-coding Testcontainers port 4566: the container port is mapped dynamically. Use getEndpoint() from the running container.
• Sharing bucket and queue names: parallel builds then observe each other's data. Add a run-specific suffix and delete resources in finally.
• Starting an annotated container manually: @Testcontainers and @Container already control lifecycle. A second owner causes duplicate starts or premature stops.
• Claiming AWS parity from local success: schedule targeted real-account checks for policies, encryption, networking, quotas, and operations your emulator does not fully implement.

Troubleshooting

Problem: LocalStack exits and says authentication is required -> Set a valid LOCALSTACK_AUTH_TOKEN in the shell and CI secret. Confirm Compose interpolation with docker compose config, but never print the resolved secret in shared logs.

Problem: Could not find a valid Docker environment -> Start Docker, verify docker version reaches the daemon, and review runner socket permissions. On alternative runtimes, follow Testcontainers' documented provider configuration instead of hard-coding a host path.

Problem: imports under org.testcontainers.containers.localstack fail -> You are mixing a Testcontainers 1.x example with 2.x dependencies. Use org.testcontainers.localstack.LocalStackContainer and artifact testcontainers-localstack.

Problem: S3 returns a connection or host-resolution error -> Keep forcePathStyle(true), use the endpoint returned by the active lifecycle, and do not replace a random mapped Testcontainers port with 4566.

Problem: SQS returns a queue URL the application cannot reach -> Build the SDK client with the correct endpoint for where the application runs. getEndpoint() is for code on the test host; another container needs a shared Docker network and a container-reachable alias.

Problem: tests pass alone but fail in parallel -> Generate unique resource names, avoid global cleanup such as deleting every bucket, and keep mutable static clients scoped to one container lifecycle. If a shared stack remains necessary, assign a namespace per CI run.

Interview Questions and Answers

The structured questions below cover the false-choice distinction, endpoint configuration, isolation, fidelity, cleanup, and CI design. In an interview, name which layer supplies AWS behavior and which layer owns lifecycle before discussing speed.

Best Practices

• Pin the LocalStack image, Testcontainers BOM, AWS SDK BOM, and test framework versions.
• Centralize endpoint, credentials, and region construction so application tests cannot silently call AWS.
• Start only the LocalStack services the suite uses, then verify readiness through supported health behavior.
• Prefer one container per test class or suite, and reset application resources between methods.
• Capture container logs on failure while redacting tokens and payloads containing sensitive data.
• Test payload content and observable outcomes, not only HTTP 200 responses or container health.
• Maintain a documented matrix showing which contracts run locally and which require real AWS.

Where To Go Next

Extend the helper with the next service your application actually uses, not every service LocalStack exposes. Add an API-level assertion around the application so the test proves business behavior instead of calling infrastructure alone. The API testing roadmap provides a progression from request checks to contract, integration, and resilience coverage.

Then create a small real-AWS suite for the gaps you recorded. Use a dedicated test account, short-lived identity federation, resource tags, unique names, automatic expiry, and a cleanup report. Keep local tests as the fast default and promote only the cloud-specific risks.

Conclusion

The LocalStack versus Testcontainers question becomes useful once you separate service fidelity from lifecycle management. LocalStack provides AWS-compatible behavior; Testcontainers gives that emulator isolated, test-owned startup, endpoint discovery, and cleanup. For most automated Java suites, combine them.

Use Compose when a shared fixed endpoint improves interactive work, and keep a focused real-AWS stage for policies, networking, quotas, encryption, and exact managed-service semantics. Run the two examples, collect timings and failure data on your own runner, then choose the lifecycle whose operational behavior matches your team.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Testcontainers vs Docker Compose Integration Tests (2026)
• dbt Tests vs Great Expectations (2026)
• Smoke vs sanity vs regression (2026)
• Stress vs soak vs spike testing (2026)
• Testcontainers for integration tests: Step by Step (2026)
• AI code review for Playwright tests (2026)