DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • When a Coding Agent Fixes the Test Instead of the Bug
  • Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
  • Your Visual Regression Suite Is Mostly Testing Anti-Aliasing
  • From Issue to Reviewable Patch: Build a Sandboxed Coding Agent With Deep Agents and Automated Tests

Trending

  • Building a Real Pipeline With senro: Monorepos, Caching, and Triggers
  • Kill the Worker, Keep the Research: Build a Recoverable LangGraph Agent on Temporal
  • Why Your AI Agent Works in the Demo and Fails in Production
  • The Twelve-Factor Agents: Building Production-Ready LLM Applications

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Testing, Tools, and Frameworks
  4. Boosting Test Performance With TestContainers

Boosting Test Performance With TestContainers

TestContainers can help when performing database tests. In this post, we take a look at how to squeeze some more performance out a TestContainers setup!

By 
Steve Chaloner
·
May. 18, 17 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
8.6K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

In my previous post on testing, I described how to use TestContainers to provide realistic test environments for database tests. This comment revealed the downside:

…as noted above, there always seems to be some drawback. In this case, the overhead of starting the Docker image and everything it contains will increase your overall build time.

As a reminder, here’s the TestContainer-specific code. Note the instance member postgres and the JUnit Rule that re-initializes it on a per-method basis:

package be.objectify.tcexample.db;

import be.objectify.tcexample.AbstractUserDaoTest;
import be.objectify.tcexample.UserDao;
import org.junit.After;
import org.junit.Before;
import org.junit.Rule;
import org.testcontainers.containers.PostgreSQLContainer;
import play.db.Database;

public class JooqUserDaoTest extends AbstractUserDaoTest implements DbTestSupport,
                                                                    TestData {

    @Rule
    public PostgreSQLContainer postgres = new PostgreSQLContainer();
    
    private Database database;
    
    @Before
    public void setup() throws Exception {
        // the database has all evolutions applied
        database = create(postgres); 
        // load some test data
        loadTestData(database); 
    }

    @After
    public void tearDown() {
        destroy(database);
    }

    @Override
    public UserDao dao() {
        return new JooqUserDao(database);
    }
}

Given that the huge increase in test duration results from Docker container start-up times, we can instead use a JUnit ClassRule to start up one container and re-use it for every test in the class. This means you should no longer run these tests in parallel, but the performance gains massively outweigh test parallelization.

package be.objectify.tcexample.db;

import be.objectify.tcexample.AbstractUserDaoTest;
import be.objectify.tcexample.UserDao;
import org.junit.After;
import org.junit.Before;
import org.junit.ClassRule;
import org.testcontainers.containers.PostgreSQLContainer;
import play.db.Database;

public class FasterJooqUserDaoTest extends AbstractUserDaoTest implements DbTestSupport,
                                                                          TestData {

    @ClassRule
    public static PostgreSQLContainer postgres = new PostgreSQLContainer();
    
    private Database database;
    
    @Before
    public void setup() throws Exception {
        database = create(postgres); 
        loadTestData(database); 
    }

    @After
    public void tearDown() {
        destroy(database);
    }

    @Override
    public UserDao dao() {
        return new JooqUserDao(database);
    }
}

The amount of time saved depends on the number of test methods in a class. I have some test classes that have upwards of 30 tests each, and in these cases, the execution time drops from minutes to seconds. Not bad for changing a couple of lines of code.

Testing

Published at DZone with permission of Steve Chaloner. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • When a Coding Agent Fixes the Test Instead of the Bug
  • Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
  • Your Visual Regression Suite Is Mostly Testing Anti-Aliasing
  • From Issue to Reviewable Patch: Build a Sandboxed Coding Agent With Deep Agents and Automated Tests

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook