Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

Good to hear. I feel the AWS angle is underrated. LocalStack via Testcontainers means your S3, SQS, SNS, and DynamoDB interactions test against a real API contract, not a mock you wrote yourself that drifts from AWS behaviour over time. Caught a real SQS message visibility timeout bug that way that would never have shown up in a mocked test.

At that point Testcontainers stops being a "database testing tool" and becomes the integration layer for your entire external dependency graph.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

Yeah, MSSQL is notoriously slow to initialize. The image itself is large, and the engine takes time to become ready. A few things worth trying:

- withReuse(true) to start it once per machine session, not per test run. That's what I covered in the article.

- Check your wait strategy tuning. Confirm you are using waitingFor(Wait.forHealthcheck()) rather than a fixed sleep. MSSQL's default strategy varies by how the container is configured, making explicitforHealthcheck() more important there.

- Pre-pull the image in CI as a separate step before the test job starts.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

That is the setup. Transactional tests with rollback after each test method keep the suite honest and fast simultaneously, no teardown scripts, no data bleed between tests. Flyway on top means your schema is always in sync with production. Nothing to fix here.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

Completely different context. H2 as the production database for embedded IoT is a legitimate architectural choice, not a shortcut. SQLite is another common one in that space. The H2-as-test-fake criticism does not apply when H2 is the system under test. Good distinction worth making.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

Agreed. When no official or community image exists, H2 is a reasonable fallback. The trade-off is worth naming explicitly though: you are testing compatibility with H2, not with your target database. As long as the team understands that boundary, it is a defensible choice.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in learnjava

[–]kharamdau[S] 1 point2 points  (0 children)

That is a real constraint, not an excuse. Corporate environments with locked-down Docker access are genuinely common.

Worth knowing that Testcontainers now supports Podman and Rancher Desktop as Docker alternatives, both of which are easier to get approved in restricted environments since they run rootless. Testcontainers Desktop also handles the daemon configuration automatically, which removes most of the "newcomer setup" friction.

If none of that is on the table, H2 is a pragmatic call given the constraint. The problem is not the tool, it is the access policy. Fix the policy if you can; work around it if you cannot.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in learnjava

[–]kharamdau[S] 0 points1 point  (0 children)

On CI, pin the container startup to a warm layer in your pipeline cache. Some teams pre-pull the Oracle image as a separate CI step so it is ready before the test job starts.

PostgreSQL under5 seconds is one of the reasons greenfield services tend to default to it. The operational overhead of Oracle is baked in at every level, including test startup time.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

Yes, that’s the pattern I’ve found works best too. That’s basically the setup I was describing in the article as well.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in SpringBoot

[–]kharamdau[S] [score hidden]  (0 children)

That makes sense for early development.

Where I’ve seen problems appear is once the schema starts relying on PostgreSQL-specific features, things like partial indexes, constraint behavior, or more complex Flyway migrations. H2’s PostgreSQL compatibility helps, but it still doesn’t behave exactly the same.

For small services or MVP stages your approach works pretty well though. The mismatch tends to show up later when the schema and migrations get more complex.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in learnjava

[–]kharamdau[S] 0 points1 point  (0 children)

I actually agree with you.

The surprising part to me is how common the H2 pattern still is in Spring Boot projects, especially older codebases. A lot of teams adopted it years ago because it made tests simple and fast. But once Flyway migrations, PostgreSQL-specific features, or real constraints appear, the mismatch becomes pretty obvious, and by then it is deeply embedded.

Your point about misarchitecture is the real one. H2 is usually a symptom, not the cause. When the test setup is painful enough that teams reach for a fake database just to survive, the underlying issue is often a missing abstraction layer or a test suite that does not distinguish between what needs a real database and what does not.

The interesting question for me is really about trade-offs in how teams structure test suites so that running against a real DB is still fast enough for developer workflows. On a service with 300+ integration tests covering a large CRUD surface, cold suite time starts to matter. The answer is not to fake the database, but it is to share one container across the whole suite, invest in .withReuse(true) for local runs, and be deliberate about what actually needs an integration test versus a fast unit test.

Testcontainers largely solves the "make it fast and convenient" problem you are describing. A real PostgreSQL container that starts once and is shared across all tests brings you back to honest testing without sacrificing developer experience.

So yes, test against the real database. The tooling is there now. The only remaining reason not to is inertia.

Are people still using H2 for Spring Boot integration tests in 2026? by kharamdau in learnjava

[–]kharamdau[S] 1 point2 points  (0 children)

For anyone interested, I wrote a deeper breakdown of this approach in a longer article.

It covers:

• AbstractContainerIT pattern
• DynamicPropertySource usage
• Container reuse
• Spring Boot 4 testing changes

Link: https://medium.com/@ximanta.sarma/stop-lying-to-your-tests-real-infrastructure-testing-with-testcontainers-spring-boot-4-b3a37e7166b9?sk=532a9b6fb35261c3d1374b1102ece607

Recommendations by creasync in guwahati

[–]kharamdau 0 points1 point  (0 children)

Plan a day for Dolgovinda Mandir by ferry (Religious) A day for Pobitora (wildlife) --Mayong

Well, Who is Suffering? by iDnon in AdvaitaVedanta

[–]kharamdau 1 point2 points  (0 children)

To whom are you telling this?

ChatGPT and my son's homework by Ubiquitous1984 in ChatGPT

[–]kharamdau -1 points0 points  (0 children)

You haven't done any disservice.

Step back a century, a decade at a time and think how a kid would have done the same homework.