mirror of
https://github.com/docker/docs.git
synced 2026-03-28 14:58:53 +07:00
## Description Migrate 17 Testcontainers guides from testcontainers.com into the Docker docs site, covering Java (14 guides), .NET (2 guides), and Node.js (1 guide). This follows up on PR #24450 which added the initial Go and Python guides. Each guide is converted from AsciiDoc to Hugo Markdown, split into multi-chapter stepper navigation, updated to the latest Testcontainers API, and verified with passing tests running in containers. Java guides use testcontainers-java 2.0.4 with the new 2.x Maven coordinates and package names (e.g., `testcontainers-postgresql`, `org.testcontainers.postgresql.PostgreSQLContainer`). The Quarkus guide uses Quarkus 3.22.3 with TC 1.x managed by the Quarkus BOM, since no released Quarkus version ships TC 2.x yet. ## How to test All code snippets have been verified by running each guide's source repository tests inside Docker containers with the Docker socket mounted. To re-run the verification, use the `/testcontainers-guides-migrator` skill included in this PR (`.claude/skills/testcontainers-guides-migrator/SKILL.md`). The skill's Step 6 documents the exact container commands and macOS Docker Desktop workarounds (host override, docker-java API version, etc.) needed to run each language's tests: ``` /testcontainers-guides-migrator I want you to verify all the guides in this branch. Do a full review, verifying that all code snippets compile, the code is executable, and ALL the tests pass. Run them as docker containers, never locally. ``` ## Related issues or tickets Supersedes #24450 (expanded from 2 guides to all 19) ## Reviews - [ ] Technical review - [ ] Editorial review - [ ] Product review --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
62 lines
1.9 KiB
Markdown
62 lines
1.9 KiB
Markdown
---
|
|
title: The problem with H2 for testing
|
|
linkTitle: The H2 problem
|
|
description: Understand why using H2 in-memory databases for testing gives false confidence.
|
|
weight: 10
|
|
---
|
|
|
|
A common practice is to use lightweight databases like H2 or HSQL as
|
|
in-memory databases for testing while using PostgreSQL, MySQL, or Oracle in
|
|
production. This approach has significant drawbacks:
|
|
|
|
- The test database might not support all features of your production database.
|
|
- SQL syntax might not be compatible between H2 and your production database.
|
|
- Tests passing with H2 don't guarantee they'll work in production.
|
|
|
|
## Example: PostgreSQL-specific syntax
|
|
|
|
Consider implementing an "upsert" — insert a product only if it doesn't
|
|
already exist. In PostgreSQL, you can use:
|
|
|
|
```sql
|
|
INSERT INTO products(id, code, name) VALUES(?,?,?) ON CONFLICT DO NOTHING;
|
|
```
|
|
|
|
This query doesn't work with H2 by default:
|
|
|
|
```text
|
|
Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement
|
|
"INSERT INTO products (id, code, name) VALUES (?, ?, ?) ON[*] CONFLICT DO NOTHING";
|
|
```
|
|
|
|
You can run H2 in PostgreSQL compatibility mode, but not all features are
|
|
supported. The inverse is also true — H2 supports `ROWNUM()` which PostgreSQL
|
|
doesn't.
|
|
|
|
Testing with a different database than production means you can't trust your
|
|
test results and must verify after deployment, defeating the purpose of
|
|
automated tests.
|
|
|
|
## The Spring Boot test using H2
|
|
|
|
A typical H2-based test looks like this:
|
|
|
|
```java
|
|
@DataJpaTest
|
|
class ProductRepositoryTest {
|
|
|
|
@Autowired
|
|
ProductRepository productRepository;
|
|
|
|
@Test
|
|
@Sql("classpath:/sql/seed-data.sql")
|
|
void shouldGetAllProducts() {
|
|
List<Product> products = productRepository.findAll();
|
|
assertEquals(2, products.size());
|
|
}
|
|
}
|
|
```
|
|
|
|
Spring Boot uses H2 automatically when it's on the classpath. The test passes,
|
|
but it doesn't catch PostgreSQL-specific issues.
|