[DSDK-67] Setup unit test

[jdabbech-ledger]

📝 Description

Setup jest

❓ Context

• JIRA or GitHub link: DSDK-67

✅ Checklist

Pull Requests must pass the CI and be code reviewed. Set as Draft if the PR is not ready.

• npx changeset was attached.
• Covered by automatic tests.
• Impact of the changes:
  • setup pnpm test scripts
  • setup jest shared config package:

packages
├── config
│   ├── jest
│   │   ├── index.js
│   |   ├── package.json // @ledgerhq/jest-config-dsdk

---

🧐 Checklist for the PR Reviewers

• The code aligns with the requirements described in the linked JIRA or GitHub issue.
• The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
• There are no undocumented trade-offs, technical debt, or maintainability issues.
• The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
• Any new dependencies have been justified and documented.
• Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

[mbertin-ledger]

Nice, but could be cool to define an test with assert true in order to run it on CI and check that it's working normally.

[aussedatlo]

Try to move jest dev dependency to `packages/config/jest/package.json``

Same for others dependencies (eslint, typescript)

[jdabbech-ledger]

Moving those depencies in the appropriates config packages doesn't work because turbo links the local folder instead of installing the dependencies of an internal package.

node_modules
├── @ledgerhq
│   ├── eslint-config-dsdk -> ../../../config/eslint
│   ├── jest-config-dsdk -> ../../../config/jest
│   └── tsconfig-dsdk -> ../../../config/typescript

I also tried to set the bin field of the config package pointing to a binary, like "bin": { "tsc": "./node_modules/.bin/tsc" } in config/typescript/package.json, the link works and the binary can be used in other packages but the first pnpm install fail

[aussedatlo]

That's sad, actually from official turbo basic example, eslint and others dev binary dependencies are not defined in the root package.json but on each apps/packages package.json that need it.

I don't know which solution is the best 🤔

• Declare in the root package.json one time, but all packages will have it
• Declare on each package, more strict but not more convenient

[jdabbech-ledger]

I guess it's a better solution to have an unique version in root package.json.
Moreover those 3 packages, eslint jest & typescript, are used by the sample app and every other external packages of the monorepo as binaries.

[aussedatlo]

LGTM 👍

[ofreyssinet-ledger]

shouldn't we keep the lint test? because at the same time lint can be failing while test is passing (unless I'm missing something)

[jdabbech-ledger]

The lint task is still executed as defined in turbo.json:

"test": {
      "dependsOn": ["build", "lint"],
}

I changed it in this PR to verify the test job in CI, but in the git workflow proposed by @mbertin-ledger the test job is only executed once a branch is merged.
So I guess you're right it should be 2 different jobs

[valpinkman]

Nice

[valpinkman]

could we create a different target only for the test files to have the jest annontations/types ?

[jdabbech-ledger]

It's possible but we would have to redefine the entire compilerOptions for the test files in that case and another extends section each module. Wouldn't it a bit overcomplex?

[valpinkman]

as build and lint are dependencies of the test script (described in your turbo.json update), pnpm test will in fact run pnpm build pnpm lint and pnpm test so I think it's a bit redundant to run both in the CI.
However, maybe lint should not be a dependency of test ? not sure how we want to handle our testing strategy (codechecks/unit/integration tests etc...)

right now this is just an observation but yeah, we need to think about it

[valpinkman]

open question: should lint be a dependency of the test suite ?