Share and learn in the Docker community.
Ok, I went through “Getting Started“ at Getting Started interestingly it shows what problems testcontainers can solve. I followed a couple of tutorials /for .Net.
I am not sure how the workflow indicated in the guide can be used for the services as Kafka, service B, cloud service….
Is there an end-to-end guide tutorial to achieve the workflow indicated in the getting started scenario
I don’t understand what they are trying to do. They state they solve the integration issue, but I don’t see how they would clone a prod DB or parts to work with it in a test environment.
That’s is not a Docker issue, so I suggest you ask the people creating the solution at that site, they link to Slack and Stackoverflow.
Can you share the link please?
You shared the link 
, all the way at the bottom of that page.
When testing your component/application, and don’t want to mock integrations to external systems, you can leverage testcontainers so it takes care of the lifecycle management of a containerized instance of those external systems target system during your tests.
You can find this Getting Started guide for .net:
If a testcontainers module exist for an external system, just use the module. You can find the catalog of existing .net modules here:
Here is the Kafka module from the catalog:
It shows how to embed this in your own test code.
Note: I am not using .net and have no idea what it needs.
Thanks meyay but let me ask the question with details. I noticed in the modules there is a MSSQL module. OK, correct me if I am mistaken: for my production DB, I need as before, create a sql server a test container (in my earlier operations I used a VM or docker container) then upload some or all database and direct the test project to it OR use directly a sql server test container, upload/restore copy of production DB and run the tests? Can I run some code in my CI/CD pipeline to run the testcontainers?
I have already done a CI/CD pipeline in Azure Devops, create a sql server docker container, run scripts to update the server, then restore database to the container, then run test T-sql scripts for integration tests. So the question is what is the difference between my approach and using Testcontainers if it melts down to do the same thing? Do TestContainers have specific methods for cloning a production environment?
From my understanding, the scope of everything you describe is beyond what test containers are used for. It really depends on the module and/or image (especially if the generic container class is used) on how to populate the data. Usually applications come with Flyway, Liquibase or something similar to create the DDL and DML to ensure the database is in a desired state, then add individual data depending on the test itself.
Testcontainer really just manages the lifecycle of ephemeral containers within your unit tests for the integration tests.
So instead of this (this is pseud code):
# arbitrary operation to ensue service is started and reachable as container
run unit tests # of course with however this is expressed for the programming language
# arbitrary operation to ensue service is stopped
You can just use this (again pseud code):
run unit tests # of course with however this is expressed for the programming language
The difference is where the responsibility of the lifecycle for this “test target” container is located. It aims to make the life of developers easier and the integration tests reliable compared to mocks.
The concept of using a database dump for tests doesn’t look like it’s aimed as integration test. It sounds like something you would do in an end-to-end test, which is not what testcontainers is used for.
OK thanks, got it, very clear
Results are ouput to the screen, are they saved somewhere? if not saved, is it possible or is there a flag to save it to results file?
When you develop unit tests, you can do whatever pleases you within the body of your test method. After all its code you write yourself.
I am not sure if I ever saw someone using a logger in unit tests in my life… Why would anyone want to do that?
People are interested in test reports that mark whether a unit test succeeded or failed, specific messages if assertion fail, and stack traces if exceptions occur during the test that. It depends on the programming language and used test framework what it can or can not do.
@meyay There are 1000 reasons for using a logger. Can you tell me why testcontainers have a method
.WithLogger
You can visit and ready "Enable logging" and see some reasons at
https://dotnet.testcontainers.org/custom_configuration/
First of all, when things goe wrong, we need to understand what/where went wrong.
2nd, Debugging purposes when tests fail. Until now, I am not sure how to save test ouput other that console display.
....
.....