Background<\/h2>\n
As part of our most recent engagement, we took some time to create a testing framework for the customer that would cover Furthermore, we wanted to test the real services, or as close to them as we could get. For us that meant Dapr, Redis<\/a>, Cosmos<\/a>, and a Storage Account<\/a>. The last 2 aren’t included in this article. <\/p>\n The problem with testing a real service is that they can be polluted with test and other dev’s data, and the test needs to account for this leading to increased boilerplate code in each test. For example, a test might check that a table has 1 more row after an insert, but what if something else has done an insert in between? True, we can keep track of IDs and such but it’d be a lot easier if we had the guarantee that we’re testing on a brand new clean environment every time. This example might be easy, but you can image how the complexity will increase with multiple services that the dev team is accessing for their own development. <\/p>\n Most real services are, and rightfully so, very well secured behind RBAC, VNets, Firewalls, credentials… you name it. How can we design a test framework that can test the integration with these services without having to go through the sometimes painful process of connecting a dev machine or a pipeline to a real system? <\/p>\n The clue was in the title of this article, Testcontainers<\/a>. That solved it for us, and I hope this article helps you to decide if our approach would also work for you and your customers. <\/p>\n To help with the clarity of this article, and to have a working and usable sample, we have distilled the solution into a bare bones repository that still maintains most of the components that were used, albeit with the names changed. Here’s a simplified diagram that illustrates the application we’ll be using for this demo. <\/p>\n A test is only useful if it gets run. We were quite mindful about how we designed the test framework to ensure that both us, and the customer, were empowered to write and run more tests, more easily. <\/p>\n The following is a high-level representation of the project structure, showing key components for integration testing:<\/p>\n The This app just sends a The order processor makes use of the And finally, the component that configures As a brief summary, when an We’ll jump to the walkthrough very quickly, but first let’s go through a diagram of what happens when a test runs: <\/p>\n This is what happens when you run the tests<\/p>\n We decided to use fixtures<\/a> to control the flow of the test. Fixtures allows us to call bits of code automatically and they have a great feature that’s incredibly useful for this framework so that we can define the scope in which each fixture is called. <\/p>\n We use the scope The rest of the fixtures in Another thing to note is the use of the keyword Having these fixtures properly configured makes it very easy to cherry pick which containers a test needs to start. in this snippet of code we can see how this particular test would start 2 containers: Each app has its own unit tests<\/code>, end to end tests<\/code> and integration tests<\/code>. For our use case, we decided that an integration test<\/code> was going to be “Any test that works across two or more components, but not all of them”, as that’d be an e2e<\/code> test. <\/p>\n![\"Application](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2025\/08\/application-diagram-scaled.png\")
<\/p>\nTest requirements<\/h2>\n
\n
Pytest<\/code> integrates well with most IDEs and test plugins.<\/li>\nProject Structure<\/h2>\n
\u251c\u2500\u2500 dapr-components\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 pubsub-component.yaml\n\u251c\u2500\u2500 order-processor\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 Dockerfile\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 app.py\n\u251c\u2500\u2500 order-publisher\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 Dockerfile\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 app.py\n\u2514\u2500\u2500 tests\n \u251c\u2500\u2500 conftest.py\n \u251c\u2500\u2500 docker-images\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 dapr\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 Dockerfile\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 pubsub-component.yaml\n \u2502\u00a0\u00a0 \u2514\u2500\u2500 orders\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 Dockerfile\n \u2502\u00a0\u00a0 \u2514\u2500\u2500 run.sh\n \u2514\u2500\u2500 test_orders.py<\/code><\/pre>\nDockerfile<\/h3>\n
Dockerfile<\/code> that builds the order-processor<\/code> and order-publisher<\/code> images is quite simple. It’s just a Python<\/code> image with the app copied into it. <\/p>\nFROM python:3.11-slim\n\nCOPY requirements.txt .\nRUN pip install -r requirements.txt\n\nWORKDIR \/app\nCOPY . \/app\n\nEXPOSE 8000\nCMD [\"uvicorn\", \"app:app\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\"]<\/code><\/pre>\norder-publisher<\/h3>\n
json<\/code> to Dapr on a POST<\/code> endpoint. It’s a simple app that doesn’t do much, but it’s enough for our sample. <\/p>\n@app.post(\"\/order\")\nasync def publish_order(request: Request):\n order_data = await request.json()\n\n # Starting the client here uses the default values and the ones in the\n # environment to create the client, therefore there's no extra config here.\n with DaprClient() as client:\n client.publish_event(\n pubsub_name='orders-pubsub',\n topic_name='orders',\n data=json.dumps(order_data),\n )\n return {\"status\": \"Order published\"}<\/code><\/pre>\norder-processor<\/h3>\n
Dapr<\/code> SDK to subscribe to the orders<\/code> topic, once a message is received we just print it the console. <\/p>\napp = Flask(__name__)\n\n# Register Dapr pub\/sub subscriptions\n@app.route('\/dapr\/subscribe', methods=['GET'])\ndef subscribe():\n subscriptions = [{\n 'pubsubname': 'orders-pubsub',\n 'topic': 'orders',\n 'route': 'orders'\n }]\n print('Dapr pub\/sub is subscribed to: ' + json.dumps(subscriptions))\n return jsonify(subscriptions)\n\n# Dapr subscription in \/dapr\/subscribe sets up this route\n@app.route('\/orders', methods=['POST'])\ndef orders_subscriber():\n event = from_http(request.headers, request.get_data())\n\n # More complicated processing would go here in a real application\n print('Received order: ' + event.data, flush=True)\n return 'OK', 200\n\napp.run(port=8001)<\/code><\/pre>\nDapr components<\/h3>\n
Redis<\/code> to be used with Dapr<\/code>.<\/p>\napiVersion: dapr.io\/v1alpha1\nkind: Component\nmetadata:\n name: orders-pubsub\n namespace: ${NAMESPACE}\nspec:\n type: pubsub.redis\n version: v1\n # Variables documented here\n # https:\/\/docs.dapr.io\/reference\/components-reference\/supported-pubsub\/setup-redis-pubsub\/\n metadata:\n - name: redisHost\n value: 127.0.0.1:6379<\/code><\/pre>\nProposed workflow<\/h2>\n
integration test<\/code> runs, we use Pytest<\/code> and testcontainers<\/code> to build, configure and start the necessary containers to run the test in an isolated environment. When the test finishes, we clean everything up for the next run. <\/p>\nDiagram<\/h3>\n
![\"Test](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2025\/08\/test-run-flow-scaled.png\")
<\/p>\nCode Walkthrough<\/h2>\n
TL;DR<\/h3>\n
1. Build standalone images\n2. Build Dapr image\n3. Create test image with Standalone and Dapr\n4. For each test\n 1. Create a Docker Network\n 2. Start and configure Containers\n 3. Run the test\n 4. Cleanup<\/code><\/pre>\nUsing Fixtures to control setup and take down<\/h3>\n
session<\/code> for the code that we want to run only once per session<\/code>. In this case we’re building the Docker images, and that’s something that we can do only once. Also notice the parameter autouse<\/code> which enables this fixture to be called every time regardless of which test starts the session. <\/p>\n@pytest.fixture(scope=\"session\", autouse=True)\ndef images():\n # This is just a helper function to simplify the code\n def create_docker_image(path: str, tag: str, buildargs: dict = None) -> DockerImage:\n return DockerImage(path=path, tag=tag).build(buildargs=buildargs)\n\n # Build the base images as they'd be deployed in production\n create_docker_image(\".\/order-processor\", processor_base)\n create_docker_image(\".\/order-publisher\", publisher_base)\n\n # This uses the base images and extends them to include test-specific\n # dependencies. In this case... just Dapr but it could also include other\n # things such as az cli or test volumes for sample payloads\n create_docker_image(\".\/tests\/docker-images\/dapr\", dapr)\n create_docker_image(\".\/tests\/docker-images\/orders\", processor,\n buildargs={\"image\": processor_base)\n<\/code><\/pre>\nconftest.py<\/code> have the scope of function<\/code> which means that they’re created and destroyed in every test execution. This guarantees that tests and side effects will not pollute each other. <\/p>\nwith<\/code>, which in combination with yield<\/code> allows us to keep the containers in scope and in Docker<\/code> until the execution resolves the with<\/code> at the end of the test. Testcontainers<\/code> will make sure to stop and cleanup at the end of the with<\/code> scope. <\/p>\n@pytest.fixture(scope=\"function\")\ndef network():\n with Network() as network:\n yield network\n\n@pytest.fixture(scope=\"function\")\ndef redis(network):\n with (RedisContainer(image=\"redis:7.4.2-alpine\")\n .with_network(network)\n .with_name(\"redis-integration\")\n .with_bind_ports(6379, 6380)) as redis_container:\n yield redis_container<\/code><\/pre>\nredis<\/code> and publisher<\/code>. Note that the cleanup is managed entirely by the fixture and not the test. <\/p>\ndef test_order_publisher(redis, publisher_container):\n # Contents omitted for simplicity\n assert True<\/code><\/pre>\nBuilding the images<\/h3>\n
Dockerfile<\/code> which creates a standalone image that can be started locally or deployed to Kubernetes<\/code>. This isn’t enough for our test as we need it to be able to work with Dapr<\/code>. It’s true that we should also have the Dapr cli<\/code> installed locally for development but if we were to use that one, there’d be conflicts with app names and ports. Let’s remember that one of our priorities is to test the real configuration and dependencies as much as possible. <\/p>\n