Thread
#typescript
    m

    mammoth-art-6111

    7 months ago
    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

    little-cartoon-10569

    7 months ago
    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

    mammoth-art-6111

    7 months ago
    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

    little-cartoon-10569

    7 months ago
    I put this in every test file:
    declare module "@pulumi/pulumi" {
      export interface OutputInstance<T> {
        promise(withUnknowns?: boolean): Promise<T>;
      }
    }
    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

    mammoth-art-6111

    7 months ago
    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

    little-cartoon-10569

    7 months ago
    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

    mammoth-art-6111

    7 months ago
    that's what i'm working with right now
    a component resource
    l

    little-cartoon-10569

    7 months ago
    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

    mammoth-art-6111

    7 months ago
    even if resolving Input<T>/Output<T>?
    l

    little-cartoon-10569

    7 months ago
    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

    mammoth-art-6111

    7 months ago
    i was wondering if the time was a result of pulumi "finishing" the graph and resolving the problem
    l

    little-cartoon-10569

    7 months ago
    Pulumi shouldn't be doing that.. that's the result of calling
    pulumi up
    , which doesn't happen during
    npm run test
    ...
    m

    mammoth-art-6111

    7 months ago
    ok, so maybe there's something leaking on my side
    i'll fill you in on progress, heh
    l

    little-cartoon-10569

    7 months ago
    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

    mammoth-art-6111

    7 months ago
    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

    little-cartoon-10569

    7 months ago
    That's a big overhead. Hopefully the jest team know about it and are working on it.
    m

    mammoth-art-6111

    6 months ago
    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