#Testing your dagger functions

1 messages · Page 1 of 1 (latest)

native marten
#

I like this pattern. How did you eventually decide on it? I see some obvious advantages, what are some possible disadvantages?

#

my naïve thought was to include tests in the main module but that probably implies now that we are shipping tests with production code, which is non-ideal. Doing it this way, for instance, sets up a scenario where a future dependency resolver can exclude them

#

Another approach would not be to include them as a dependency, but rather a separate module entirely, which decouples them for dependency resolution which is probably also not ideal

tawdry holly
#

Originally, I had a single module called ci (much like how I have one in my "application" type projects, so I got the idea from there).

As the number of modules grew in my daggerverse repo, running that single CI module became incredibly slow. (Some numbers: at some point CI for that module ran on average in about 5 minutes for each module. It's around 40-50 seconds now)

I wanted a universal pattern that I can easily follow and automate running CI for. I knew including every module in a single test module as a dependency made things incredibly slow, so splitting each into their own module seemed like the logical next step.

The reason I have them in the main module directory is because it's easier to interact with them this way:

# in main module
dagger develop

dagger .... do something

# run develop in tests
dagger develop -m tests

# run a test
dagger call -m tests some-test
#

Some people call that module dev and do other kinds of stuff, like testing terminals during development.

The name is less important in this case IMO.

native marten
#

interesting, my initial desire was to make a "ci" module as well... good to know this is an antipattern at scale

#

it seems like it makes sense to do that for apps, but not your monorepo/daggerverse/reusable one

tawdry holly
#

the problem is number of dependencies. it can easily become an issue for an app too. hopefully caching will become better.

Although I was kinda forced to move away from that pattern, but I kinda prefer this new one. Easier to work with/develop the module, more portable, etc.

native marten
#

shame you can't exclude/hide/tag modules from the registry yet... checking your namespace in daggerverse has a bunch of modules called "tests"

#

probably a glob to exclude publishing those (though maybe there is a legit use case for publishing them) would be the most straightforward solution

tawdry holly
#

@nova aurora @arctic pelican @odd jackal need to hear your opinion 😃

nova aurora
#

sorry I missed this somehow

#

Testing your dagger functions

#

There are 2 questions here:

  1. What is the best practice for tightly coupling a Dagger module to the development of a specific software project? (this is what the contextual modules proposal attempts to solve)

  2. Should the same best practice also apply when the software project is itself a Dagger module? Or is there a separate, special best practice just for that? ( @stray folio mentioned the possibility of a module having the ability to test itself, with specially marked test functions - similar to test_xxx.go in go.

stray folio
odd jackal
#

👋 FWIW I'm prototyping this here: https://github.com/dagger/dagger/issues/7217. I'm about to wrap a PR so we can start iterating on that UX. The main reason to pursue this initial approach is so we can leverage what users are currently doing without having to make considerable changes in the engine. Having said that, if we make a change so tests can be written alongside your module, a bunch of that work will be surely reused 🙏

GitHub
Issues · dagger/dagger

Application Delivery as Code that Runs Anywhere. Contribute to dagger/dagger development by creating an account on GitHub.

fathom mantle
#

thanks for jumping in folks, main reason for me to use dagger is precisely the possibility to include testing in the ci components itself, looking forward to seeing that testing approach.

mossy drum
#

would the chosen language SDKs most common/default unit testing framework be the most logical route that would happen? That's what comes to my mind without even thinking about it (but im a total newbie to dagger)

nova aurora
#

Yes that would make sense to me

#

Since we shipped dagger functions, I don't know how well that integration with native test frameworks works... cc @placid oriole who pioneered that pattern in the early days of our multi-language design.

maybe @gentle plover has opinions on this too

native marten
#

I personally would prefer an opinionated take on test frameworks for this use case, given the performance concerns raised above by Mark

#

if dagger team offers a golden path it gives the ability to optimize better, IMHO

#

(or maybe caching story just gets good enough that this doesn't really matter)