unit-tests to check ‘shortAddr’ function

[DS-jr]

No description provided.

[DS-jr]

@tectonick
Please, check the error (appears during tests) in line N2 here:
a666fd6#diff-4d1c553a7ecea861c38acd7d95cd197a7c0e6dd1210d3c3197aa2d87a8715dc2R2

[tectonick]

“@DS-jr, I think the root cause of this error is that the shared/lib/utils child import, @twa-dev/sdk, uses the window object itself during module initialization. Test environments like Jest or Vitest don’t include the window object from the browser API by default because tests are not run in a browser environment. However, this can be easily circumvented by adding additional packages that make the window object available in tests. For Vitest, it’s just a matter of setting the environment option to jsdom or happy-dom in the vite.config.js file. You can add the following configuration to your vite.config.js:

export default defineConfig({
  // other config options
  test: {
    environment: 'jsdom'
    // other test options 
  }
});

[DS-jr]

@tectonick
Fixed previous bugs with this commit:
acf8d52

Unit-tests are working ok after that.

If NO new bugs / mistakes in my code - please, confirm that #48 can be closed.

[DS-jr]

@tectonick
About this commit:
​​acf8d52

I’ve changed manually only several lines of code (Ex.: added "jsdom" dependency), but 200+ modifications happened in the repo according to git.

This is how JS dependencies are updated automatically without my involvement, correct?

[tectonick]

I would suggest removing commented out code, it's not needed under source control.

[tectonick]

It's not expected during correct mocking to have such error TypeError: vi.mocked(...).mockReturnValueOnce is not a function.
The vi.mocked function allows TypeScript users to cast an object to a mocked type, although it does not offer any mocking functionality on its own.
Check this doc https://vitest.dev/guide/mocking.html, it shows good examples of correct mocking in vitest.

[tectonick]

@tectonick About this commit:​​acf8d52

I’ve changed manually only several lines of code (Ex.: added "jsdom" dependency), but 200+ modifications happened in the repo according to git.

This is how JS dependencies are updated automatically without my involvement, correct?

@DS-jr it's ok. A package lock file is generated by package managers like npm, pnpm or yarn. It serves as a snapshot of the exact versions of all dependencies and their transitive dependencies installed in a project at a given time. Its changes should be committed to the git repository.