https://pulumi.com logo
Join Slack
Powered by
is there a way to unit test and use the "regular" ...
# typescript
m
is there a way to unit test and use the "regular" matching functions? seems a shame that Output<T> makes reasonable unit testing difficult
l
I use mocha and regular matching functions. To get it working, I use Mocha's promise support (there's a package called mocha-as-promised or similar) and expose the 
promise()
method in outputs, which I call in every assertion. Hopefully jest also supports promises like this?
m
how did you go about exposing the 
promise()
method?
did you inherit and expose via a base class? or did you do something else? also running into some really long test times w/ pulumi, any way you ran into to speed that up? personally wondering why it takes so long when all i'm doing is verifying some basic stuff
l
I put this in every test file:
Copy code
declare module "@pulumi/pulumi" {
  export interface OutputInstance<T> {
    promise(withUnknowns?: boolean): Promise<T>;
  }
}
🙏 1
When unit testing, tests are really fast unless you accidentally have some AWS SDK (or similar) in your ComponentResources. Don't unit test anything that makes a real connection to a cloud resource.
It's really helped me isolate external dependencies: any time a test is slow, I know there's something "real" going on, and I extract it.
m
does pulumi mock/not make network calls when orchestrating resources? i don't have anything that calls via AWS CLI/SDK but i have pulumi resources that are being called in some functions under test
it was my assumption pulumi doesn't communicate over the network during testing
l
That depends on what you're calling 🙂 It runs in test mode, so the resources won't be hooked up to providers and all their internal connections will be faked (not mocked). But if you are importing index.ts, then your code will run, so if it does anything external (e.g. manually create a provider) then that happens.
I recommend only importing ComponentResource class files and testing them. It fits with my OO-education and it has worked well for me.
m
that's what i'm working with right now
a component resource
l
It shouldn't be slow. There could well be an initial overhead as Mocha and Pulumi warm up, but each test should be roughly constant time, in the order of 10s of ms or less.
m
even if resolving Input<T>/Output<T>?
l
If you've got a specific MCVE test, reworked to work with promise(), and with a small class (maybe copied into the same file), then I'm happy to review a gist and see if I can see anything to improve.
m
i was wondering if the time was a result of pulumi "finishing" the graph and resolving the problem
l
Pulumi shouldn't be doing that.. that's the result of calling 
pulumi up
, which doesn't happen during 
npm run test
...
m
ok, so maybe there's something leaking on my side
i'll fill you in on progress, heh
👍 1
l
Re:
even if resolving Input<T>/Output<T>?
This can be variable, but since there are no real dependencies to wait on, all awaiting should resolve very, very quickly. There's always an overhead with promises in Node, which is why we can't reasonably expect sub-millisecond tests, but sub-10ms tests are very achieveable.
m
right i'm seeing seconds, not milliseconds
5s runs
digging into it, it seems to be an issue with jest, not necessarily the tests themselves, something is causing the jest setup/teardown to take about 10s
the wall time on the test suite itself is like ~1s for 11 tests
i installed 
nock
and blocked all http requests, nothing is going out as far as I can tell
looks like ts-jest is just slow
what ended up speeding it up was setting 
isolatedModules
to true, which removes a lot of type-checking power but I guess you can get that via CI linter checks
reduced it from 10s to 2s startup time
l
That's a big overhead. Hopefully the jest team know about it and are working on it.
m
did you ever try jest btw? or did you just stick w/ mocha
currently going back to mocha because i ran into a bug w/ jest that i think is a little bit of a showstopper, but having a really hard time setting up typescript-style paths with it, even w/ 
tsconfig-paths
it doesn't seem to work appropriately, i'm wondering if it's because Pulumi plays with env vars on the process, particularly 
process.env.TS_NODE_PROJECT
19 Views
Open in Slack
PreviousNext
Powered by