#Breakpoint debugging with Dagger in Go tests

1 messages · Page 1 of 1 (latest)

fair cloak
#

Hey Dagger team!

I like Dagger and I'm trying to find a good way to use it in testing, both locally and CI.

I've looked at your https://github.com/dagger/dagger/tree/main/.dagger and assume that you even call dagger call test locally. How fast is that for you? I git cloned your repo and ran it and it took very long.

  • I like to run tests quickly via the play buttons in my IDE and use the debug with breakpoints feature.
  • I like to run tests quickly since many tests need k3s, and k3s take a bit to start; I'm letting tests start once k3s, but don't stop it to have faster next tests.

To have this DX, should replace my current non-dagger inital-start logic with dagger call to run the integrations (k3s, pq, temporal, ...)? I want those integrations started by dagger to outlive a single test that started them.

What I don't think is a fast DX loop is have a dagger (t *Test) Specific function. It takes too long.

GitHub

An engine to run your pipelines in containers. Contribute to dagger/dagger development by creating an account on GitHub.

GitHub

An engine to run your pipelines in containers. Contribute to dagger/dagger development by creating an account on GitHub.

#

I think I could use Go’s TestMain to start up integrations services.

#

What I’m confusing probably is do my tests call dagger or dagger call my tests haha.

#

The first option would be better for DX, the latter for in CI env

#

I want to reuse the same logic to setup the services local and in CI. Dagger is good for that. But I want to be able to run go test outside Dagger locally but inside remotely.