🤖 we've been adopting the testcontainers pattern from our own tests: test code orchestrate

[young quartz]

Yep. Concrete examples:

• e2e/helm/k3s.go: newK3S builds the dependency as Dagger objects: a k3s Service plus a kubeconfig File, not a Go client: https://github.com/dagger/dagger/blob/1be1867fd879109586a39d8a8d999eaf44604fee/e2e/helm/k3s.go#L15-L56
• e2e/helm/helm_test.go: the test owns lifecycle/wiring: start k3s, cleanup, bind it into the Helm/kubectl container, mount kubeconfig, run assertions: https://github.com/dagger/dagger/blob/1be1867fd879109586a39d8a8d999eaf44604fee/e2e/helm/helm_test.go#L95-L180
• core/integration/engine_test.go: same idea for Dagger-in-Dagger: helpers produce a nested engine service and a client container pointed at it: https://github.com/dagger/dagger/blob/1be1867fd879109586a39d8a8d999eaf44604fee/core/integration/engine_test.go#L48-L152
• core/integration/engine_persistence_test.go: a test-specific wrapper starts/tunnels the nested engine and constructs the SDK client from its endpoint: https://github.com/dagger/dagger/blob/1be1867fd879109586a39d8a8d999eaf44604fee/core/integration/engine_persistence_test.go#L39-L65

For Kwok, I’d mirror the k3s shape: have the Kwok module expose the cluster service plus kubeconfig/endpoint. Let the test/dev module own the Kubernetes client and lifecycle, because the test knows whether it wants kubectl, client-go, Helm, cleanup behavior, parallelism, etc. A convenience helper returning a preconfigured client/container is fine, but I wouldn’t hide the dependency lifecycle inside the Kwok module.

💻 🌎

Dagger testcontainers-style tests

Dagger testcontainers-style tests
Found the historical core/integration conversion PR: dagger/dagger#11746, Dogfood "testcontainers" pattern in our integration test harness. It was opened by shykes, later picked up by Kyle/kpenfound on the ci-engine-tests branch, closed unmerged as stale on 2026-04-24. Kyle's supporting PR #11949 for generated-client/engine fixes merged on 2026-03-10 and explicitly references #11746.

[marsh shadow]

@young quartz also find the pull request by Kyle attempting to convert all of core/integration to this pattern.

[young quartz]

Found it: https://github.com/dagger/dagger/pull/11746

Title: Dogfood "testcontainers" pattern in our integration test harness. It’s the big attempted core/integration conversion: 73 commits, 85 files, ~26k additions. GitHub shows it opened by Solomon, but Kyle picked it up later on the same branch: latest commits are by kpenfound, and Kyle comments that it was waiting on the supporting generated-client/engine fixes.

Useful related link: Kyle’s supporting PR, merged, explicitly says it contains fixes required for #11746: https://github.com/dagger/dagger/pull/11949

#11746 was closed unmerged by stale automation on 2026-04-24.

💻 🌎

[weary token]

although I found it to be a pretty trivial lift from the provided examples by swapping dagger.io/dagger imports to a package generated by dagger client install ..., I wanted to call out that you don't appear to be dogfooding that particular pattern.

I only mention this as I recall you saying that you wanted to support that--and, indeed, I have found it useful to rely on existing modules to orchestrate some more complex dependencies

[marsh shadow]

yes you're right. e2e didn't need modules really. core/integration really does - for that engine dev build

[misty whale]

This is for testing non-dagger code with dagger right? When ready, I hope this will be well documented with examples. It can be a easy way to get adoption

[marsh shadow]

more specifically to allow non-dagger test code to use dagger modules to setup its dependencies