hi! has anyone gotten unit tests with typescript a...
# typescript
f
hi! has anyone gotten unit tests with typescript and ESM working? when I have a package with
"type": "module"
in my package.json i get errors running mocha unit tests. i get errors trying to import files in my tests. i have set the ts-node/esm loader in in my .mocharc.json:
Copy code
{
  "extension": [
    "ts"
  ],
  "loader": "ts-node/esm",
  "spec": "tests/**/*_test.ts",
  "recursive": true
}
and i have
"esm": true
in my tsconfig.json:
Copy code
{
  "compilerOptions": {
    "module": "ES2020",
    "target": "ES2020",
    "moduleResolution": "node",
    "esModuleInterop": true
  },
  "ts-node": {
    "compilerOptions": {
      "module": "esnext"
    },
    "esm": true
  }
}
(to be honest I probably don't need the ts-node block because i would expect es2020 and esnext to have the same effect for the purposes of this scenario, but I don't know much about es2020/esnext particulars). i have been looking at issues such as https://github.com/TypeStrong/ts-node/issues/935. would appreciate if anyone has any pointers on this, thanks!
the errors I get are like this:
Copy code
Error: Cannot find module '/home/myuser/path/pulumi-component-resources/my_component' imported from /home/myuser/path/pulumi-component-resources/tests/my_component_test.ts
and i am doing the import like this
Copy code
before(async function () {
    // It's important to import the program _after_ the mocks are defined.
    module = await import("../my_component");
  });
the ts file does exist in the place expected
l
Yes, they work for me (using jest). I don't have an issue with imports having to happen after fakes (usually, not mocks) are defined, because I define only classes in other modules.
f
hm interesting, i'm just using mocha because the example used mocha. so to be clear, ES modules are working for you with jest? it sounds like it's kinda experimental (though that might be the case for both jest and mocha at the moment.) thanks!
l
Yes, all working. I did have a few compilation issues initially, and they were tricky enough that I refactored my directory structure to ensure that no directory was both a Pulumi project and an NPM package, but it's all working cleanly now. I'll post snippets of a working tsconfig.json and package.json, onesec.
f
that would be awesome, thank you!
l
Not much of interest in package.json:
Copy code
{
  "name": "project",
  "type": "module",
  "module": "esnext",
  "target": "es2020",
   ...
This is slightly more interesting.
s
does anyone know of good examples of writing tests in for pulumi TS?
l
No. All the examples are bad.
Tests seem to be very hard for developers. I rarely see good tests in any platform.
s
if you start a good repo for pulumi and maybe they will hire you
l
That'd be nice, but unfortunately they aren't set up to hire in my country yet. Maybe some day!
s
bitcoin contractor. there are zero problems a motivated company will not do to hire someone they like.
I have seen companies hire teenagers in Kuwait just because a manager gets in love with someone
l
Separate conversation, but: if someone offers to pay in crypto, they're going on a blacklist that I'm distributing to everyone I ever met.
s
fine by me I'll take the crypto.
l
Anyway, back to the actual topic. The rules are: 1. Don't use Pulumi state methods, config methods, stack references or anything like that. They all go in your index.ts and don't get unit tested. 2. Expose the
promise()
method on
OutputInstance<>
. 3. For AWS resources, set the ARN in your resource creation function in
setMocks()
. You'll need to soooo often. The recommendations are: 1. Write your tests before your code. 2. Don't write tests, describe decisions you've made about how you want your project to work. 3. Keep your tests short.
177 Views