Skip to content
This repository has been archived by the owner on May 11, 2022. It is now read-only.

Setup Testing Framework #320

Merged
merged 16 commits into from
Jan 19, 2022
Merged

Setup Testing Framework #320

merged 16 commits into from
Jan 19, 2022

Conversation

sentilesdal
Copy link
Contributor

Gets a testing framework setup using Jest, Waffle and Testing Library. I've included some sample tests for the useDelegate hook. There were a lot of hurdles overcome which I'll layout here:

Jest Configuration:
We are using Jest version 26, not 27. Because we need to use testEnvironment: 'jsdom', We had to downgrade the version of Jest since jsdom in Jest 27 is incompatible with some of our dependencies. I had to bring in the jest-environment-jsdom package and extend jsdom as outlined in this github issue. I also had to update the moduleFileExtensions and transform jest config properties to handle our tsx and css files.

Waffle:
In order to get waffle to work, I had to get the contracts to use the MockProvider during testing. Also, the contracts need a static list of addresses at compile time, so I had to deploy the contracts to waffle, get their addresses and then make an addresses file. If we change the deployment setup, we'll need to regenerate this file.

Testing Library:
A lot of the issues here were solved by getting jsdom working with jest. In addition, most of our hooks use react-query for data fetching which uses the QueryClient context. So, we need to pass a wrapper to renderHook to provide that context. This will be necessary for any hook that uses react-query.

Caveats still to fix:

  • test suite hangs instead of exiting gracefully
  • need to set up global beforeAll to deploy contracts so that we don't incur a 10s setup per file.
  • we are using a global MockProvider, so tests need to be run sequentially

@vercel
Copy link

vercel bot commented Jan 15, 2022

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

elf-council-frontend – ./

🔍 Inspect: https://vercel.com/element-finance/elf-council-frontend/Fg6G2piCFXPqPGXftaTuDnEtRcHX
✅ Preview: https://elf-council-frontend-git-matt-add-example-test-element-finance.vercel.app

elf-council-frontend-storybook – ./

🔍 Inspect: https://vercel.com/element-finance/elf-council-frontend-storybook/7SEB88w3LXTvCnYReTn2VdPBLkxC
✅ Preview: https://elf-council-frontend-storybook-git-matt-82ac92-element-finance.vercel.app

export const ALCHEMY_GOERLI_HTTP_URL = `https://eth-goerli.alchemyapi.io/v2/${ALCHEMY_GOERLI_KEY}`;
export const ALCHEMY_MAINNET_HTTP_URL = `https://eth-mainnet.alchemyapi.io/v2/${ALCHEMY_MAINNET_KEY}`;

export const testProvider = new MockProvider();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? It's the same as defaultProvider when in "test".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, we don't need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah I remember, it's easier for maintaining the 'MockProvider' type, otherwise we'd have to either return a union type or typecast every time we import.

"extends": [
"next",
"react-app",
"plugin:@typescript-eslint/eslint-recommended",
"plugin:@typescript-eslint/recommended",
"plugin:testing-library/react",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add this one too while we're here: https://github.com/testing-library/eslint-plugin-jest-dom

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice find!

jest.config.ts Outdated
// watchPathIgnorePatterns: [],

// Whether to use watchman for file crawling
// watchman: true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: remove all the commented stuff now that the initial config is all set up

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took out most, leaving in some coverage ones because I'm going to tweak these soon. I might add an example jest config file because the comments are actually the default values, which are nice to know about.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants