![\"Testcontainers](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/9-2.png\")
<\/a>Docker for a manual tester<\/strong><\/strong><\/h2>\n\n\n\nIf you’ve dealt with databases, you probably recall your own effort to prepare a DB working environment “from scratch”. Even if it’s just a local environment, you need to have a DB driver and client, as well as set everything up properly, creating a valid connection string. This is especially important in case of Oracle databases.<\/p>\n\n\n\n
It all can be done much more efficiently using Docker. Docker’s central image repository<\/a> contains an ever-expanding database of images, including Oracle database images. The manufacturer presents its official images, but other developers also provide their own versions. In short \u2013 we have all versions of almost any tool in one place<\/strong>.<\/p>\n\n\n\nI am choosing an Oracle version, e.g. 9, represented by a Docker tag, and can apply a command that downloads the image to a local disk:<\/p>\n\n\n\n
![\"Download](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/1-3.png\")
<\/a>Fig. 2 Download image command<\/figcaption><\/figure><\/div>\n\n\n\nThe benefit is significant, because what will appear on our disk in the form of a docker image [image] already contains everything we need to use the database. The next command [docker run], which will start the container, will make the database available for work.<\/p>\n\n\n\n
![\"Run](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/2-3.png\")
<\/a>Fig. 3 Run container command<\/a><\/figcaption><\/figure><\/div>\n\n\n\nIn the description of a given image, the author usually provides already prepared commands in various versions. All you need to do is run them locally in the Windows console.<\/p>\n\n\n\n
Advantages and disadvantages of the solution<\/strong><\/h2>\n\n\n\nI’m not saying that handling Docker is trivial, but I’m putting forward a thesis that once someone tries it, they won’t go back<\/strong> to the demanding installations and tedious configurations of desktop versions.<\/p>\n\n\n\nThere\u2019s also significant saving in disk space. Installation of a native tool almost always takes up much more disk space than a Docker image.<\/p>\n\n\n\n
Downsides and inconveniences<\/strong> include the one-time installation of Docker itself. It is a console tool, but on Windows you can use Docker Desktop, which allows you to manage Docker images and containers transparently.<\/p>\n\n\n\n![\"Docker](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/3-3.png\")
<\/a>Fig. 4 Docker Desktop<\/a><\/figcaption><\/figure><\/div>\n\n\n\nIt must also be admitted that we need to master the console commands, which will allow us to move in Docker freely. However, this is mainly a time effort, because I confidently say that free knowledge sources on the subject<\/a> available on the web are sufficient and there is no need to invest in paid trainings<\/strong> in case of a manual tester.<\/p>\n\n\n\nDocker for an automation tester and developer<\/strong><\/strong><\/h2>\n\n\n\nDevelopers have already come to appreciate Docker and are taking full advantage of it. We launch a container with any application instantly (a matter of milliseconds), use it and close it just as quickly. When saving the state of an application doesn’t matter to us, it is completely seamless. There is also no trouble if communication is needed between the local disk and the container, e.g. by sending a file to the container or receiving a file from the container to the disk.<\/p>\n\n\n\n
It is also possible to run multiple containers at the same time and connect them into one network.<\/p>\n\n\n\n
Testcontainers<\/strong><\/h2>\n\n\n\nHowever, there is a challenge for testing applications that use containers, especially those based on microservice architecture. Integration testing is a phase during which we want to test the joint operation of different system components, e.g. Rest API and the database, or the microservice that produces messages for Kafka and consumes these messages along with the Kafka broker.<\/p>\n\n\n\n
When preparing automated integration tests for such an architecture, it is necessary to use a database container<\/strong>, e.g. PostgreSQL or a queue, e.g. Kafka. This container must be run in the code.<\/p>\n\n\n\nThis is where Testcontainers comes to the scene. It is a library that provides API for running Docker containers in the code<\/strong>. The tool supports the following programming languages:<\/p>\n\n\n\n- Java,<\/li>
- Go,<\/li>
- .NET,<\/li>
- Python,<\/li>
- Node.js,<\/li>
- Rust.<\/li><\/ul>\n\n\n\n
![\"Programming](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/4a.png\")
<\/a>Fig. 5 Programming languages supported by Testcontainers<\/a><\/a><\/figcaption><\/figure><\/div>\n\n\n\nThe library provides automatic management of starting and closing containers as soon as the test is completed. It is an extremely “aesthetic” approach. The environment of the tested application is built relatively quickly (about 2-3 extra seconds) automatically just before the test. Then the logic of our scenarios is executed and the result returned, and finally the container disappears irretrievably.<\/p>\n\n\n\n
This “ephemerality” for an automation tester is extremely attractive. Testcontainers provides a mechanism for preparing test data “on the fly”. Also, the need to clean up the state after a test, for the sake of ensuring that artifacts and left-over data do not inadvertently affect subsequent executions of the same test, disappears. Here, each test run has its own “fresh” component instance, which disappears after the test, along with all its contents.<\/p>\n\n\n\n
Testcontainers\/ryuk<\/strong><\/h3>\n\n\n\nThe object that manages closing selected containers is “testcontainers\/ryuk<\/strong>“. It always starts, even though we do not explicitly declare it in the code. It is a privileged container<\/strong> that is responsible for the correct and automatic closure of containers [automatic cleanup].<\/p>\n\n\n\nThis mechanism is of great importance, especially when we stop the execution of tests in a non-standard way, for example:<\/p>\n\n\n\n
- an exception occurs during the scenario execution,<\/li>
- the full test environment couldn\u2019t be run because one container was missing,<\/li>
- during debugging we close the test from the IDE level.<\/li><\/ul>\n\n\n\n
All these and similar situations force the closure of running containers, to not leave “dead containers” in the memory. Although the library’s documentation allows your own ryuk<\/strong> configuration, or even disabling it, it is not recommended.<\/p>\n\n\n\nTestcontainers for JAVA language \u2013 demo<\/strong><\/strong><\/h2>\n\n\n\nI will present a practical example of Testcontainers usage in a Java code. I want to use a PostgreSQL database as a component during [Controller] testing in a simple microservice. I have chosen Micronaut framework, but it would work just as well with the traditional Spring Boot.<\/p>\n\n\n\n
The service is a classic CRUD \u2013 it allows reading, saving, editing and deleting Actor entities to the database. It contains division into layers:<\/p>\n\n\n\n
- Controller,<\/li>
- Service,<\/li>
- Repository,<\/li><\/ul>\n\n\n\n
In Micronaut, such model class will look as follows:<\/p>\n\n\n
\npackage com.example;\n\nimport io.micronaut.core.annotation.Nullable;\nimport io.micronaut.data.annotation.GeneratedValue;\nimport io.micronaut.data.annotation.MappedEntity;\nimport io.swagger.v3.oas.annotations.media.Schema;\nimport javax.persistence.Entity;\nimport javax.persistence.GenerationType;\nimport javax.persistence.Id;\nimport javax.validation.constraints.NotBlank;\nimport javax.validation.constraints.Size;\n\n@Schema(description="Actor business model")\n@Entity\npublic class Actor\n {\n @GeneratedValue @Id\n @Nullable\n private Long id;\n @NotBlank @Size(max = 20)\n private String firstName;\n @NotBlank @Size(max = 20)\n private String lastName;\n @NotBlank\n private Long rating;\n\n\/\/getters and setters\n}\n[src\/main\/java\/model\/Actor] \n<\/pre><\/div>\n\n\nI have defined DataSource in the configuration file application.ymk<\/strong> for Postgres, which looks as follows:<\/p>\n\n\n\ndatasources:\n default:\n url: jdbc:postgresql:\/\/localhost:5432\/actor\n driverClassName: org.postgresql.Driver\n username: postgres\n password: postgres\n schema-generate: NONE\n dialect: POSTGRES\n schema: public\n<\/pre><\/div>\n\n\nWhen the database with the right schema is running, everything works flawlessly. I can run my API tests written, for example, in REST-Assured. However, if I disable the database, no test will give reliable results. Testcontainers will allow me to “turn on” the missing component only for the time of running my tests.<\/p>\n\n\n\n
The first step is to download the dependencies to the project:<\/p>\n\n\n\n
Maven<\/strong>:<\/p>\n\n\n\n<dependency>\n <groupId>org.junit.jupiter<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>5.8.1<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>testcontainers<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<\/pre><\/div>\n\n\nGradle<\/strong>:<\/p>\n\n\n\ntestImplementation "org.junit.jupiter:junit-jupiter:5.8.1"\ntestImplementation "org.testcontainers:testcontainers:1.17.6"\ntestImplementation "org.testcontainers:junit-jupiter:1.17.6"\n<\/pre><\/div>\n\n\nI then define the DataSource at the test level. In Micronaut, the application-test.yml<\/strong> configuration file is responsible for it:<\/p>\n\n\n\ndatasources:\ndefault:\nurl: jdbc:tc:postgresql:latest:\/\/\/postgres?TC_INITSCRIPT=file:src\/test\/resources\/init-actor-testdata.sql?TC_DAEMON=true\n \tdriverClassName: org.testcontainers.jdbc.ContainerDatabaseDriver\n \tminimum-idle: 5\n<\/pre><\/div>\n\n\nNote that the url parameter is marked with tc<\/strong> \u2013 [jdbc:tc] \u2013 indicating that its operation will be handled by Testcontainers. Additionally, driverClassName also contains an indication of the org.testcontainers package.<\/p>\n\n\n\nNow we can mark in the test class code that we will use Docker containers with annotation @Testcontainers<\/strong> before the class.<\/p>\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n}\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nAnd with @Container annotation before a field, which defines the type and version of the container:<\/p>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nThe other annotations left are:<\/p>\n\n\n\n
- @MicronautTest(environments = “test”) \u2013 a Micronaut annotation to indicate that we will be using the Micronaut test context.<\/li>
- @Slf4j \u2013 Lombok annotation that starts the logger in a class.<\/li><\/ul>\n\n\n\n
The PostgreSQLContainer class provides us with proper operation of this detailed PostgreSQL container. Moreover, there is a generic class GenericContainer, which we can always use to store the object of any container:<\/p>\n\n\n
\n@Container\n private static final GenericContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n<\/pre><\/div>\n\n\nThe Testcontainers library requires that we add the absolute minimum and necessary configuration of our container. After all, we have to choose which postgres image we need, define the schema name, username and password.<\/p>\n\n\n\n
Personally, I prefer to put such configuration not in the test class, but in a separate class responsible for postgres containers. It makes sense because postgres is not the only component we could potentially need. When Kafka, Redis or MongoDB appear, we will safely separate all these configurations<\/strong>.<\/p>\n\n\n\nThe code for such class might look as follows:<\/p>\n\n\n
\npackage com.example.containers;\n\nimport org.testcontainers.containers.PostgreSQLContainer;\nimport org.testcontainers.utility.DockerImageName;\n\npublic class PostgresContainer extends PostgreSQLContainer<PostgresContainer> {\n private static final String MYPOSTGRESIMAGE = "postgres:latest" ;\n private static final String MYTESTDATABASENAME = "actor";\n private static final String USERNAME = "postgres";\n private static final String PASSWD = "postgres";\n private static final Integer DB_PORT = 5432;\n\n private PostgresContainer() {\n super(DockerImageName.parse(MYPOSTGRESIMAGE));\n }\n\n public static PostgreSQLContainer<?> getContainerPostgres() {\n return new PostgreSQLContainer<>(DockerImageName.parse(MYPOSTGRESIMAGE))\n .withDatabaseName(MYTESTDATABASENAME)\n .withExposedPorts(DB_PORT)\n .withUsername(USERNAME)\n .withPassword(PASSWD);\n }\n}\n[src\/test\/containers\/PostgresContainer]\n<\/pre><\/div>\n\n\nThe static method – getContainerPostgres() is the most relevant here. At this place with the use of multiple methods beginning with “with” we set the state of our container and ways of connecting to it.<\/p>\n\n\n\n
The string mode of calling these methods adds tremendous convenience:<\/p>\n\n\n\n![\"tryb](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/4-2.png\")
<\/figure>\n\n\n\nNow all that is left is to transfer the container connection details with the database to the test DataSource. Together with the Micronaut @MockBean annotation, it is very simple and in the test class can look as follows:<\/p>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n private DataSource postgresDataSource;\n\n private JdbcTemplate jdbcTemplate;\n\n @Inject\n public JdbcTemplateExampleTest(DataSource postgresDataSource) {\n this.postgresDataSource = postgresDataSource;\n }\n\n @MockBean(DBConnector.class)\n DBConnector postgresConnection() {\n PostgresTestContainer dbConnection = new PostgresTestContainer();\n dbConnection.setUrl(postgres.getJdbcUrl());\n dbConnection.setUsername(postgres.getUsername());\n dbConnection.setPasswd(postgres.getPassword());\n return dbConnection;\n }\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nVisible in the class bean JdbcTemplate served me only as a connector to the database. Thanks to it we’ll know that the database will actually show up when we need it, because we’ll be able to execute our queries and receive the results.<\/p>\n\n\n\n
When everything is prepared I can implement two simple tests:<\/p>\n\n\n\n
- Test 1 – shouldGetAllActorsFromDBBasedOnTestContainers() \u2013 retrieve all the actors from the database – “SELECT * FROM actor”;<\/li>
- Test 2 – shouldGetSingleActorFromDBBasedOnTestContainers() \u2013 retrieve one actor from the database – “SELECT firstname FROM actor WHERE id=1”;<\/li><\/ul>\n\n\n
\n@Test\n void shouldGetAllActorsFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getLoadedRecords();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults.get(0).get("firstname")).isEqualTo("Brad");\n assertThat(dbResults.get(1).get("firstname")).isEqualTo("Angelina");\n assertThat(dbResults.get(2).get("firstname")).isEqualTo("Salma");\n }\n\n @Test\n void shouldGetSingleActorFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getSingleRecord();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults).isEqualTo("Brad");\n }\n\n private boolean isRecordLoaded() {\n return jdbcTemplate.queryForList("Select * from actor").size() > 1;\n }\n\n private List<Map<String, Object>> getLoadedRecords() {\n return jdbcTemplate.queryForList("Select * from actor");\n }\n\n private String getSingleRecord() {\n return jdbcTemplate.queryForObject("Select firstname from actor where id=1", String.class);\n }\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nResults<\/strong><\/h3>\n\n\n\nHere are the results of a test class run locally in the IDE. Note how the logs in the console clearly indicate that:<\/p>\n\n\n\n
- Docker started,<\/li>
- the privileged Testcontainers\/ryuk container started,<\/li>
- the PostgreSQL container started.<\/li><\/ul>\n\n\n\n
And most importantly, the execution time of both tests is only 0.5 sec<\/strong>!<\/p>\n\n\n\n![\"Rezultaty](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/5-2-1024x383.png\")
Fig. 6 Results of a test class run in the local IDE<\/figcaption><\/figure>\n\n\n\nAdditionally, to confirm, I am adding a view from Docker Desktop at the time of test execution. You can clearly see that the needed containers are in the running status:<\/p>\n\n\n\n
![\"Widok](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/6-2-1024x268.png\")
<\/a>Fig. 7 View from Docker Desktop during test execution<\/figcaption><\/figure><\/div>\n\n\n\nYou can see how Testcontainers allowed me to implement whichever integration tests with minimal effort. The necessary components “get up” as Docker containers, and after the test is executed, the components are deleted.<\/p>\n\n\n\n
There is one other issue that I find extremely useful in Testcontainers. These are options (flags) that I define in the<\/strong> configuration file<\/strong> application-test.yml:<\/p>\n\n\n\n- TC_INITSCRIPT<\/li>
- TC_DAEMON<\/li><\/ul>\n\n\n\n
![\"Flagi](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/7-2-1024x139.png\")
<\/a>Fig. 8 Flags defined in the application-test.yml configuration file<\/figcaption><\/figure><\/div>\n\n\n\nTC_INITSCRIPT<\/strong><\/h3>\n\n\n\nIt is understandable that when we use a database, we would like the schema, tables and some test data necessary to execute the test to already be there. Thanks to the TC_INITSCRIPT option, we can define an SQL script, which will run as soon as the DB container is started, but before the first line of code is executed.<\/p>\n\n\n\n
In my demo, I used the following script, so I didn’t have to handle the contents of my PostgreSQL database in the test code:<\/p>\n\n\n\n
![\"Skrypt](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/03\/8-2-1024x396.png\")
<\/a>Fig. 9 Skrypt src\/test\/resources\/init-actor-testdata.sql<\/figcaption><\/figure><\/div>\n\n\n\nTC_DAEMON<\/strong><\/h3>\n\n\n\nIn the default setting, the database container is stopped after the last connection is closed. However, there are times when we will want the container to run until it is explicitly stopped or the JVM is turned off. To do this, add the TC_DAEMON parameter to the URL, as in the graphic above.<\/p>\n\n\n\n
Summary<\/strong><\/h2>\n\n\n\nTestcontainers is a library for handling Docker containers in the code. It is perfect<\/strong> for creating ephemeral components in automated integration tests. It also allows you to load SQL scripts in such a way that the container database is already equipped with the schema and data necessary for testing.<\/p>\n\n\n\nWhile working with Testcontainers, I noticed two inconveniences<\/strong>:<\/p>\n\n\n\n- you need to have experience working with external Java libraries. Individual implementation is not trivial, as Docker itself is non-trivial. The intellectual entry threshold is therefore noticeable, but I can clearly see the effort of this library creators to make the job as simple as possible for developers,<\/li>
- after working in Testcontainers all day and running integration tests repeatedly, I notice that Docker, especially Docker Desktop on Windows OS, can consume a large amount of computer resources (RAM, CPU). Many times the containers do not “get up” and the test ends with an “Initialization error”. We can then configure a range of dedicated resources for Docker in the .wslconfig file. When the container initialization error recurs, the most effective way is to simply restart the computer.<\/li><\/ul>\n\n\n\n
***
If you are interested in the subject of Docker, we encourage you to read a series of articles prepared by our expert (PL):<\/p>\n\n\n\n
- Docker dla programist\u00f3w: co to jest?<\/a><\/li>
- Docker dla programist\u00f3w \u2013 budowa pierwszego \u015brodowiska. Cz\u0119\u015b\u0107 I<\/a><\/li>
- Docker dla programist\u00f3w \u2013 budowa \u015brodowiska rozwojowego. Cz\u0119\u015b\u0107 II<\/a><\/li>
- Docker dla programist\u00f3w \u2013 dystrybucja aplikacji <\/a><\/li><\/ul>\n\n\n
I am choosing an Oracle version, e.g. 9, represented by a Docker tag, and can apply a command that downloads the image to a local disk:<\/p>\n\n\n\n
<\/a>The benefit is significant, because what will appear on our disk in the form of a docker image [image] already contains everything we need to use the database. The next command [docker run], which will start the container, will make the database available for work.<\/p>\n\n\n\n
<\/a>In the description of a given image, the author usually provides already prepared commands in various versions. All you need to do is run them locally in the Windows console.<\/p>\n\n\n\n
Advantages and disadvantages of the solution<\/strong><\/h2>\n\n\n\nI’m not saying that handling Docker is trivial, but I’m putting forward a thesis that once someone tries it, they won’t go back<\/strong> to the demanding installations and tedious configurations of desktop versions.<\/p>\n\n\n\nThere\u2019s also significant saving in disk space. Installation of a native tool almost always takes up much more disk space than a Docker image.<\/p>\n\n\n\n
Downsides and inconveniences<\/strong> include the one-time installation of Docker itself. It is a console tool, but on Windows you can use Docker Desktop, which allows you to manage Docker images and containers transparently.<\/p>\n\n\n\n<\/a>Fig. 4 Docker Desktop<\/a><\/figcaption><\/figure><\/div>\n\n\n\nIt must also be admitted that we need to master the console commands, which will allow us to move in Docker freely. However, this is mainly a time effort, because I confidently say that free knowledge sources on the subject<\/a> available on the web are sufficient and there is no need to invest in paid trainings<\/strong> in case of a manual tester.<\/p>\n\n\n\nDocker for an automation tester and developer<\/strong><\/strong><\/h2>\n\n\n\nDevelopers have already come to appreciate Docker and are taking full advantage of it. We launch a container with any application instantly (a matter of milliseconds), use it and close it just as quickly. When saving the state of an application doesn’t matter to us, it is completely seamless. There is also no trouble if communication is needed between the local disk and the container, e.g. by sending a file to the container or receiving a file from the container to the disk.<\/p>\n\n\n\n
It is also possible to run multiple containers at the same time and connect them into one network.<\/p>\n\n\n\n
Testcontainers<\/strong><\/h2>\n\n\n\nHowever, there is a challenge for testing applications that use containers, especially those based on microservice architecture. Integration testing is a phase during which we want to test the joint operation of different system components, e.g. Rest API and the database, or the microservice that produces messages for Kafka and consumes these messages along with the Kafka broker.<\/p>\n\n\n\n
When preparing automated integration tests for such an architecture, it is necessary to use a database container<\/strong>, e.g. PostgreSQL or a queue, e.g. Kafka. This container must be run in the code.<\/p>\n\n\n\nThis is where Testcontainers comes to the scene. It is a library that provides API for running Docker containers in the code<\/strong>. The tool supports the following programming languages:<\/p>\n\n\n\n- Java,<\/li>
- Go,<\/li>
- .NET,<\/li>
- Python,<\/li>
- Node.js,<\/li>
- Rust.<\/li><\/ul>\n\n\n\n
<\/a>Fig. 5 Programming languages supported by Testcontainers<\/a><\/a><\/figcaption><\/figure><\/div>\n\n\n\nThe library provides automatic management of starting and closing containers as soon as the test is completed. It is an extremely “aesthetic” approach. The environment of the tested application is built relatively quickly (about 2-3 extra seconds) automatically just before the test. Then the logic of our scenarios is executed and the result returned, and finally the container disappears irretrievably.<\/p>\n\n\n\n
This “ephemerality” for an automation tester is extremely attractive. Testcontainers provides a mechanism for preparing test data “on the fly”. Also, the need to clean up the state after a test, for the sake of ensuring that artifacts and left-over data do not inadvertently affect subsequent executions of the same test, disappears. Here, each test run has its own “fresh” component instance, which disappears after the test, along with all its contents.<\/p>\n\n\n\n
Testcontainers\/ryuk<\/strong><\/h3>\n\n\n\nThe object that manages closing selected containers is “testcontainers\/ryuk<\/strong>“. It always starts, even though we do not explicitly declare it in the code. It is a privileged container<\/strong> that is responsible for the correct and automatic closure of containers [automatic cleanup].<\/p>\n\n\n\nThis mechanism is of great importance, especially when we stop the execution of tests in a non-standard way, for example:<\/p>\n\n\n\n
- an exception occurs during the scenario execution,<\/li>
- the full test environment couldn\u2019t be run because one container was missing,<\/li>
- during debugging we close the test from the IDE level.<\/li><\/ul>\n\n\n\n
All these and similar situations force the closure of running containers, to not leave “dead containers” in the memory. Although the library’s documentation allows your own ryuk<\/strong> configuration, or even disabling it, it is not recommended.<\/p>\n\n\n\nTestcontainers for JAVA language \u2013 demo<\/strong><\/strong><\/h2>\n\n\n\nI will present a practical example of Testcontainers usage in a Java code. I want to use a PostgreSQL database as a component during [Controller] testing in a simple microservice. I have chosen Micronaut framework, but it would work just as well with the traditional Spring Boot.<\/p>\n\n\n\n
The service is a classic CRUD \u2013 it allows reading, saving, editing and deleting Actor entities to the database. It contains division into layers:<\/p>\n\n\n\n
- Controller,<\/li>
- Service,<\/li>
- Repository,<\/li><\/ul>\n\n\n\n
In Micronaut, such model class will look as follows:<\/p>\n\n\n
\npackage com.example;\n\nimport io.micronaut.core.annotation.Nullable;\nimport io.micronaut.data.annotation.GeneratedValue;\nimport io.micronaut.data.annotation.MappedEntity;\nimport io.swagger.v3.oas.annotations.media.Schema;\nimport javax.persistence.Entity;\nimport javax.persistence.GenerationType;\nimport javax.persistence.Id;\nimport javax.validation.constraints.NotBlank;\nimport javax.validation.constraints.Size;\n\n@Schema(description="Actor business model")\n@Entity\npublic class Actor\n {\n @GeneratedValue @Id\n @Nullable\n private Long id;\n @NotBlank @Size(max = 20)\n private String firstName;\n @NotBlank @Size(max = 20)\n private String lastName;\n @NotBlank\n private Long rating;\n\n\/\/getters and setters\n}\n[src\/main\/java\/model\/Actor] \n<\/pre><\/div>\n\n\nI have defined DataSource in the configuration file application.ymk<\/strong> for Postgres, which looks as follows:<\/p>\n\n\n\ndatasources:\n default:\n url: jdbc:postgresql:\/\/localhost:5432\/actor\n driverClassName: org.postgresql.Driver\n username: postgres\n password: postgres\n schema-generate: NONE\n dialect: POSTGRES\n schema: public\n<\/pre><\/div>\n\n\nWhen the database with the right schema is running, everything works flawlessly. I can run my API tests written, for example, in REST-Assured. However, if I disable the database, no test will give reliable results. Testcontainers will allow me to “turn on” the missing component only for the time of running my tests.<\/p>\n\n\n\n
The first step is to download the dependencies to the project:<\/p>\n\n\n\n
Maven<\/strong>:<\/p>\n\n\n\n<dependency>\n <groupId>org.junit.jupiter<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>5.8.1<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>testcontainers<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<\/pre><\/div>\n\n\nGradle<\/strong>:<\/p>\n\n\n\ntestImplementation "org.junit.jupiter:junit-jupiter:5.8.1"\ntestImplementation "org.testcontainers:testcontainers:1.17.6"\ntestImplementation "org.testcontainers:junit-jupiter:1.17.6"\n<\/pre><\/div>\n\n\nI then define the DataSource at the test level. In Micronaut, the application-test.yml<\/strong> configuration file is responsible for it:<\/p>\n\n\n\ndatasources:\ndefault:\nurl: jdbc:tc:postgresql:latest:\/\/\/postgres?TC_INITSCRIPT=file:src\/test\/resources\/init-actor-testdata.sql?TC_DAEMON=true\n \tdriverClassName: org.testcontainers.jdbc.ContainerDatabaseDriver\n \tminimum-idle: 5\n<\/pre><\/div>\n\n\nNote that the url parameter is marked with tc<\/strong> \u2013 [jdbc:tc] \u2013 indicating that its operation will be handled by Testcontainers. Additionally, driverClassName also contains an indication of the org.testcontainers package.<\/p>\n\n\n\nNow we can mark in the test class code that we will use Docker containers with annotation @Testcontainers<\/strong> before the class.<\/p>\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n}\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nAnd with @Container annotation before a field, which defines the type and version of the container:<\/p>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nThe other annotations left are:<\/p>\n\n\n\n
- @MicronautTest(environments = “test”) \u2013 a Micronaut annotation to indicate that we will be using the Micronaut test context.<\/li>
- @Slf4j \u2013 Lombok annotation that starts the logger in a class.<\/li><\/ul>\n\n\n\n
The PostgreSQLContainer class provides us with proper operation of this detailed PostgreSQL container. Moreover, there is a generic class GenericContainer, which we can always use to store the object of any container:<\/p>\n\n\n
\n@Container\n private static final GenericContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n<\/pre><\/div>\n\n\nThe Testcontainers library requires that we add the absolute minimum and necessary configuration of our container. After all, we have to choose which postgres image we need, define the schema name, username and password.<\/p>\n\n\n\n
Personally, I prefer to put such configuration not in the test class, but in a separate class responsible for postgres containers. It makes sense because postgres is not the only component we could potentially need. When Kafka, Redis or MongoDB appear, we will safely separate all these configurations<\/strong>.<\/p>\n\n\n\nThe code for such class might look as follows:<\/p>\n\n\n
\npackage com.example.containers;\n\nimport org.testcontainers.containers.PostgreSQLContainer;\nimport org.testcontainers.utility.DockerImageName;\n\npublic class PostgresContainer extends PostgreSQLContainer<PostgresContainer> {\n private static final String MYPOSTGRESIMAGE = "postgres:latest" ;\n private static final String MYTESTDATABASENAME = "actor";\n private static final String USERNAME = "postgres";\n private static final String PASSWD = "postgres";\n private static final Integer DB_PORT = 5432;\n\n private PostgresContainer() {\n super(DockerImageName.parse(MYPOSTGRESIMAGE));\n }\n\n public static PostgreSQLContainer<?> getContainerPostgres() {\n return new PostgreSQLContainer<>(DockerImageName.parse(MYPOSTGRESIMAGE))\n .withDatabaseName(MYTESTDATABASENAME)\n .withExposedPorts(DB_PORT)\n .withUsername(USERNAME)\n .withPassword(PASSWD);\n }\n}\n[src\/test\/containers\/PostgresContainer]\n<\/pre><\/div>\n\n\nThe static method – getContainerPostgres() is the most relevant here. At this place with the use of multiple methods beginning with “with” we set the state of our container and ways of connecting to it.<\/p>\n\n\n\n
The string mode of calling these methods adds tremendous convenience:<\/p>\n\n\n\n<\/figure>\n\n\n\nNow all that is left is to transfer the container connection details with the database to the test DataSource. Together with the Micronaut @MockBean annotation, it is very simple and in the test class can look as follows:<\/p>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n private DataSource postgresDataSource;\n\n private JdbcTemplate jdbcTemplate;\n\n @Inject\n public JdbcTemplateExampleTest(DataSource postgresDataSource) {\n this.postgresDataSource = postgresDataSource;\n }\n\n @MockBean(DBConnector.class)\n DBConnector postgresConnection() {\n PostgresTestContainer dbConnection = new PostgresTestContainer();\n dbConnection.setUrl(postgres.getJdbcUrl());\n dbConnection.setUsername(postgres.getUsername());\n dbConnection.setPasswd(postgres.getPassword());\n return dbConnection;\n }\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nVisible in the class bean JdbcTemplate served me only as a connector to the database. Thanks to it we’ll know that the database will actually show up when we need it, because we’ll be able to execute our queries and receive the results.<\/p>\n\n\n\n
When everything is prepared I can implement two simple tests:<\/p>\n\n\n\n
- Test 1 – shouldGetAllActorsFromDBBasedOnTestContainers() \u2013 retrieve all the actors from the database – “SELECT * FROM actor”;<\/li>
- Test 2 – shouldGetSingleActorFromDBBasedOnTestContainers() \u2013 retrieve one actor from the database – “SELECT firstname FROM actor WHERE id=1”;<\/li><\/ul>\n\n\n
\n@Test\n void shouldGetAllActorsFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getLoadedRecords();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults.get(0).get("firstname")).isEqualTo("Brad");\n assertThat(dbResults.get(1).get("firstname")).isEqualTo("Angelina");\n assertThat(dbResults.get(2).get("firstname")).isEqualTo("Salma");\n }\n\n @Test\n void shouldGetSingleActorFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getSingleRecord();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults).isEqualTo("Brad");\n }\n\n private boolean isRecordLoaded() {\n return jdbcTemplate.queryForList("Select * from actor").size() > 1;\n }\n\n private List<Map<String, Object>> getLoadedRecords() {\n return jdbcTemplate.queryForList("Select * from actor");\n }\n\n private String getSingleRecord() {\n return jdbcTemplate.queryForObject("Select firstname from actor where id=1", String.class);\n }\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nResults<\/strong><\/h3>\n\n\n\nHere are the results of a test class run locally in the IDE. Note how the logs in the console clearly indicate that:<\/p>\n\n\n\n
- Docker started,<\/li>
- the privileged Testcontainers\/ryuk container started,<\/li>
- the PostgreSQL container started.<\/li><\/ul>\n\n\n\n
And most importantly, the execution time of both tests is only 0.5 sec<\/strong>!<\/p>\n\n\n\nFig. 6 Results of a test class run in the local IDE<\/figcaption><\/figure>\n\n\n\nAdditionally, to confirm, I am adding a view from Docker Desktop at the time of test execution. You can clearly see that the needed containers are in the running status:<\/p>\n\n\n\n
<\/a>Fig. 7 View from Docker Desktop during test execution<\/figcaption><\/figure><\/div>\n\n\n\nYou can see how Testcontainers allowed me to implement whichever integration tests with minimal effort. The necessary components “get up” as Docker containers, and after the test is executed, the components are deleted.<\/p>\n\n\n\n
There is one other issue that I find extremely useful in Testcontainers. These are options (flags) that I define in the<\/strong> configuration file<\/strong> application-test.yml:<\/p>\n\n\n\n- TC_INITSCRIPT<\/li>
- TC_DAEMON<\/li><\/ul>\n\n\n\n
<\/a>Fig. 8 Flags defined in the application-test.yml configuration file<\/figcaption><\/figure><\/div>\n\n\n\nTC_INITSCRIPT<\/strong><\/h3>\n\n\n\nIt is understandable that when we use a database, we would like the schema, tables and some test data necessary to execute the test to already be there. Thanks to the TC_INITSCRIPT option, we can define an SQL script, which will run as soon as the DB container is started, but before the first line of code is executed.<\/p>\n\n\n\n
In my demo, I used the following script, so I didn’t have to handle the contents of my PostgreSQL database in the test code:<\/p>\n\n\n\n
<\/a>Fig. 9 Skrypt src\/test\/resources\/init-actor-testdata.sql<\/figcaption><\/figure><\/div>\n\n\n\nTC_DAEMON<\/strong><\/h3>\n\n\n\nIn the default setting, the database container is stopped after the last connection is closed. However, there are times when we will want the container to run until it is explicitly stopped or the JVM is turned off. To do this, add the TC_DAEMON parameter to the URL, as in the graphic above.<\/p>\n\n\n\n
Summary<\/strong><\/h2>\n\n\n\nTestcontainers is a library for handling Docker containers in the code. It is perfect<\/strong> for creating ephemeral components in automated integration tests. It also allows you to load SQL scripts in such a way that the container database is already equipped with the schema and data necessary for testing.<\/p>\n\n\n\nWhile working with Testcontainers, I noticed two inconveniences<\/strong>:<\/p>\n\n\n\n- you need to have experience working with external Java libraries. Individual implementation is not trivial, as Docker itself is non-trivial. The intellectual entry threshold is therefore noticeable, but I can clearly see the effort of this library creators to make the job as simple as possible for developers,<\/li>
- after working in Testcontainers all day and running integration tests repeatedly, I notice that Docker, especially Docker Desktop on Windows OS, can consume a large amount of computer resources (RAM, CPU). Many times the containers do not “get up” and the test ends with an “Initialization error”. We can then configure a range of dedicated resources for Docker in the .wslconfig file. When the container initialization error recurs, the most effective way is to simply restart the computer.<\/li><\/ul>\n\n\n\n
***
If you are interested in the subject of Docker, we encourage you to read a series of articles prepared by our expert (PL):<\/p>\n\n\n\n
- Docker dla programist\u00f3w: co to jest?<\/a><\/li>
- Docker dla programist\u00f3w \u2013 budowa pierwszego \u015brodowiska. Cz\u0119\u015b\u0107 I<\/a><\/li>
- Docker dla programist\u00f3w \u2013 budowa \u015brodowiska rozwojowego. Cz\u0119\u015b\u0107 II<\/a><\/li>
- Docker dla programist\u00f3w \u2013 dystrybucja aplikacji <\/a><\/li><\/ul>\n\n\n
There\u2019s also significant saving in disk space. Installation of a native tool almost always takes up much more disk space than a Docker image.<\/p>\n\n\n\n
Downsides and inconveniences<\/strong> include the one-time installation of Docker itself. It is a console tool, but on Windows you can use Docker Desktop, which allows you to manage Docker images and containers transparently.<\/p>\n\n\n\n It must also be admitted that we need to master the console commands, which will allow us to move in Docker freely. However, this is mainly a time effort, because I confidently say that free knowledge sources on the subject<\/a> available on the web are sufficient and there is no need to invest in paid trainings<\/strong> in case of a manual tester.<\/p>\n\n\n\n Developers have already come to appreciate Docker and are taking full advantage of it. We launch a container with any application instantly (a matter of milliseconds), use it and close it just as quickly. When saving the state of an application doesn’t matter to us, it is completely seamless. There is also no trouble if communication is needed between the local disk and the container, e.g. by sending a file to the container or receiving a file from the container to the disk.<\/p>\n\n\n\n It is also possible to run multiple containers at the same time and connect them into one network.<\/p>\n\n\n\n However, there is a challenge for testing applications that use containers, especially those based on microservice architecture. Integration testing is a phase during which we want to test the joint operation of different system components, e.g. Rest API and the database, or the microservice that produces messages for Kafka and consumes these messages along with the Kafka broker.<\/p>\n\n\n\n When preparing automated integration tests for such an architecture, it is necessary to use a database container<\/strong>, e.g. PostgreSQL or a queue, e.g. Kafka. This container must be run in the code.<\/p>\n\n\n\n This is where Testcontainers comes to the scene. It is a library that provides API for running Docker containers in the code<\/strong>. The tool supports the following programming languages:<\/p>\n\n\n\n The library provides automatic management of starting and closing containers as soon as the test is completed. It is an extremely “aesthetic” approach. The environment of the tested application is built relatively quickly (about 2-3 extra seconds) automatically just before the test. Then the logic of our scenarios is executed and the result returned, and finally the container disappears irretrievably.<\/p>\n\n\n\n This “ephemerality” for an automation tester is extremely attractive. Testcontainers provides a mechanism for preparing test data “on the fly”. Also, the need to clean up the state after a test, for the sake of ensuring that artifacts and left-over data do not inadvertently affect subsequent executions of the same test, disappears. Here, each test run has its own “fresh” component instance, which disappears after the test, along with all its contents.<\/p>\n\n\n\n The object that manages closing selected containers is “testcontainers\/ryuk<\/strong>“. It always starts, even though we do not explicitly declare it in the code. It is a privileged container<\/strong> that is responsible for the correct and automatic closure of containers [automatic cleanup].<\/p>\n\n\n\n This mechanism is of great importance, especially when we stop the execution of tests in a non-standard way, for example:<\/p>\n\n\n\n All these and similar situations force the closure of running containers, to not leave “dead containers” in the memory. Although the library’s documentation allows your own ryuk<\/strong> configuration, or even disabling it, it is not recommended.<\/p>\n\n\n\n I will present a practical example of Testcontainers usage in a Java code. I want to use a PostgreSQL database as a component during [Controller] testing in a simple microservice. I have chosen Micronaut framework, but it would work just as well with the traditional Spring Boot.<\/p>\n\n\n\n The service is a classic CRUD \u2013 it allows reading, saving, editing and deleting Actor entities to the database. It contains division into layers:<\/p>\n\n\n\n In Micronaut, such model class will look as follows:<\/p>\n\n\n I have defined DataSource in the configuration file application.ymk<\/strong> for Postgres, which looks as follows:<\/p>\n\n\n When the database with the right schema is running, everything works flawlessly. I can run my API tests written, for example, in REST-Assured. However, if I disable the database, no test will give reliable results. Testcontainers will allow me to “turn on” the missing component only for the time of running my tests.<\/p>\n\n\n\n The first step is to download the dependencies to the project:<\/p>\n\n\n\n Maven<\/strong>:<\/p>\n\n\n Gradle<\/strong>:<\/p>\n\n\n I then define the DataSource at the test level. In Micronaut, the application-test.yml<\/strong> configuration file is responsible for it:<\/p>\n\n\n Note that the url parameter is marked with tc<\/strong> \u2013 [jdbc:tc] \u2013 indicating that its operation will be handled by Testcontainers. Additionally, driverClassName also contains an indication of the org.testcontainers package.<\/p>\n\n\n\n Now we can mark in the test class code that we will use Docker containers with annotation @Testcontainers<\/strong> before the class.<\/p>\n\n\n And with @Container annotation before a field, which defines the type and version of the container:<\/p>\n\n\n The other annotations left are:<\/p>\n\n\n\n The PostgreSQLContainer class provides us with proper operation of this detailed PostgreSQL container. Moreover, there is a generic class GenericContainer, which we can always use to store the object of any container:<\/p>\n\n\n The Testcontainers library requires that we add the absolute minimum and necessary configuration of our container. After all, we have to choose which postgres image we need, define the schema name, username and password.<\/p>\n\n\n\n Personally, I prefer to put such configuration not in the test class, but in a separate class responsible for postgres containers. It makes sense because postgres is not the only component we could potentially need. When Kafka, Redis or MongoDB appear, we will safely separate all these configurations<\/strong>.<\/p>\n\n\n\n The code for such class might look as follows:<\/p>\n\n\n The static method – getContainerPostgres() is the most relevant here. At this place with the use of multiple methods beginning with “with” we set the state of our container and ways of connecting to it.<\/p>\n\n\n\n The string mode of calling these methods adds tremendous convenience:<\/p>\n\n\n\n Now all that is left is to transfer the container connection details with the database to the test DataSource. Together with the Micronaut @MockBean annotation, it is very simple and in the test class can look as follows:<\/p>\n\n\n Visible in the class bean JdbcTemplate served me only as a connector to the database. Thanks to it we’ll know that the database will actually show up when we need it, because we’ll be able to execute our queries and receive the results.<\/p>\n\n\n\n When everything is prepared I can implement two simple tests:<\/p>\n\n\n\n Here are the results of a test class run locally in the IDE. Note how the logs in the console clearly indicate that:<\/p>\n\n\n\n And most importantly, the execution time of both tests is only 0.5 sec<\/strong>!<\/p>\n\n\n\n Additionally, to confirm, I am adding a view from Docker Desktop at the time of test execution. You can clearly see that the needed containers are in the running status:<\/p>\n\n\n\n You can see how Testcontainers allowed me to implement whichever integration tests with minimal effort. The necessary components “get up” as Docker containers, and after the test is executed, the components are deleted.<\/p>\n\n\n\n There is one other issue that I find extremely useful in Testcontainers. These are options (flags) that I define in the<\/strong> configuration file<\/strong> application-test.yml:<\/p>\n\n\n\n It is understandable that when we use a database, we would like the schema, tables and some test data necessary to execute the test to already be there. Thanks to the TC_INITSCRIPT option, we can define an SQL script, which will run as soon as the DB container is started, but before the first line of code is executed.<\/p>\n\n\n\n In my demo, I used the following script, so I didn’t have to handle the contents of my PostgreSQL database in the test code:<\/p>\n\n\n\n In the default setting, the database container is stopped after the last connection is closed. However, there are times when we will want the container to run until it is explicitly stopped or the JVM is turned off. To do this, add the TC_DAEMON parameter to the URL, as in the graphic above.<\/p>\n\n\n\n Testcontainers is a library for handling Docker containers in the code. It is perfect<\/strong> for creating ephemeral components in automated integration tests. It also allows you to load SQL scripts in such a way that the container database is already equipped with the schema and data necessary for testing.<\/p>\n\n\n\n While working with Testcontainers, I noticed two inconveniences<\/strong>:<\/p>\n\n\n\n ***<\/a>Docker for an automation tester and developer<\/strong><\/strong><\/h2>\n\n\n\n
Testcontainers<\/strong><\/h2>\n\n\n\n
<\/a>Testcontainers\/ryuk<\/strong><\/h3>\n\n\n\n
Testcontainers for JAVA language \u2013 demo<\/strong><\/strong><\/h2>\n\n\n\n
\npackage com.example;\n\nimport io.micronaut.core.annotation.Nullable;\nimport io.micronaut.data.annotation.GeneratedValue;\nimport io.micronaut.data.annotation.MappedEntity;\nimport io.swagger.v3.oas.annotations.media.Schema;\nimport javax.persistence.Entity;\nimport javax.persistence.GenerationType;\nimport javax.persistence.Id;\nimport javax.validation.constraints.NotBlank;\nimport javax.validation.constraints.Size;\n\n@Schema(description="Actor business model")\n@Entity\npublic class Actor\n {\n @GeneratedValue @Id\n @Nullable\n private Long id;\n @NotBlank @Size(max = 20)\n private String firstName;\n @NotBlank @Size(max = 20)\n private String lastName;\n @NotBlank\n private Long rating;\n\n\/\/getters and setters\n}\n[src\/main\/java\/model\/Actor] \n<\/pre><\/div>\n\n\n\ndatasources:\n default:\n url: jdbc:postgresql:\/\/localhost:5432\/actor\n driverClassName: org.postgresql.Driver\n username: postgres\n password: postgres\n schema-generate: NONE\n dialect: POSTGRES\n schema: public\n<\/pre><\/div>\n\n\n
\n<dependency>\n <groupId>org.junit.jupiter<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>5.8.1<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>testcontainers<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<dependency>\n <groupId>org.testcontainers<\/groupId>\n <artifactId>junit-jupiter<\/artifactId>\n <version>1.17.6<\/version>\n <scope>test<\/scope>\n<\/dependency>\n<\/pre><\/div>\n\n\n
\ntestImplementation "org.junit.jupiter:junit-jupiter:5.8.1"\ntestImplementation "org.testcontainers:testcontainers:1.17.6"\ntestImplementation "org.testcontainers:junit-jupiter:1.17.6"\n<\/pre><\/div>\n\n\n
\ndatasources:\ndefault:\nurl: jdbc:tc:postgresql:latest:\/\/\/postgres?TC_INITSCRIPT=file:src\/test\/resources\/init-actor-testdata.sql?TC_DAEMON=true\n \tdriverClassName: org.testcontainers.jdbc.ContainerDatabaseDriver\n \tminimum-idle: 5\n<\/pre><\/div>\n\n\n
\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n}\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\n\n@Container\n private static final GenericContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n<\/pre><\/div>\n\n\n
\npackage com.example.containers;\n\nimport org.testcontainers.containers.PostgreSQLContainer;\nimport org.testcontainers.utility.DockerImageName;\n\npublic class PostgresContainer extends PostgreSQLContainer<PostgresContainer> {\n private static final String MYPOSTGRESIMAGE = "postgres:latest" ;\n private static final String MYTESTDATABASENAME = "actor";\n private static final String USERNAME = "postgres";\n private static final String PASSWD = "postgres";\n private static final Integer DB_PORT = 5432;\n\n private PostgresContainer() {\n super(DockerImageName.parse(MYPOSTGRESIMAGE));\n }\n\n public static PostgreSQLContainer<?> getContainerPostgres() {\n return new PostgreSQLContainer<>(DockerImageName.parse(MYPOSTGRESIMAGE))\n .withDatabaseName(MYTESTDATABASENAME)\n .withExposedPorts(DB_PORT)\n .withUsername(USERNAME)\n .withPassword(PASSWD);\n }\n}\n[src\/test\/containers\/PostgresContainer]\n<\/pre><\/div>\n\n\n<\/figure>\n\n\n\n\n@Testcontainers\n@MicronautTest(environments = "test")\n@Slf4j\npublic class JdbcTemplateActorTest {\n\n @Container\n private static final PostgreSQLContainer<?> postgres = PostgresContainer.getContainerPostgres();\n\n private DataSource postgresDataSource;\n\n private JdbcTemplate jdbcTemplate;\n\n @Inject\n public JdbcTemplateExampleTest(DataSource postgresDataSource) {\n this.postgresDataSource = postgresDataSource;\n }\n\n @MockBean(DBConnector.class)\n DBConnector postgresConnection() {\n PostgresTestContainer dbConnection = new PostgresTestContainer();\n dbConnection.setUrl(postgres.getJdbcUrl());\n dbConnection.setUsername(postgres.getUsername());\n dbConnection.setPasswd(postgres.getPassword());\n return dbConnection;\n }\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\n\n@Test\n void shouldGetAllActorsFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getLoadedRecords();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults.get(0).get("firstname")).isEqualTo("Brad");\n assertThat(dbResults.get(1).get("firstname")).isEqualTo("Angelina");\n assertThat(dbResults.get(2).get("firstname")).isEqualTo("Salma");\n }\n\n @Test\n void shouldGetSingleActorFromDBBasedOnTestContainers() {\n jdbcTemplate = new JdbcTemplate(postgresDataSource);\n await().atMost(10, TimeUnit.SECONDS)\n .until(this::isRecordLoaded);\n\n var dbResultsSize = this.getLoadedRecords().size();\n var dbResults = this.getSingleRecord();\n\n assertThat(dbResultsSize).isEqualTo(3);\n assertThat(dbResults).isEqualTo("Brad");\n }\n\n private boolean isRecordLoaded() {\n return jdbcTemplate.queryForList("Select * from actor").size() > 1;\n }\n\n private List<Map<String, Object>> getLoadedRecords() {\n return jdbcTemplate.queryForList("Select * from actor");\n }\n\n private String getSingleRecord() {\n return jdbcTemplate.queryForObject("Select firstname from actor where id=1", String.class);\n }\n\n[src\/test\/java\/ JdbcTemplateActorTest]\n<\/pre><\/div>\n\n\nResults<\/strong><\/h3>\n\n\n\n
<\/a><\/a>TC_INITSCRIPT<\/strong><\/h3>\n\n\n\n
<\/a>TC_DAEMON<\/strong><\/h3>\n\n\n\n
Summary<\/strong><\/h2>\n\n\n\n
If you are interested in the subject of Docker, we encourage you to read a series of articles prepared by our expert (PL):<\/p>\n\n\n\n