Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test readme (hardhat fixture) #507

Merged
merged 1 commit into from
Mar 2, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions test/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,8 @@ A few key details to note about our testing implementation:

- Tests are intended to be wholly deterministic, and should not rely on any external resources.
- Tests should be able to be run in any order, and should not rely on any state from previous tests.
- Tests should utilize [Hardhat fixtures](https://hardhat.org/tutorial/testing-contracts#reusing-common-test-setups-with-fixtures) to efficiently setup tests.
- We typically use a fixture named `_beforeEach` to setup tests in a given file, similar to how `beforeEach` is used in Mocha, but with all the speed benefits of Hardhat fixtures. Additionally, we typically return a single `config` object from the `_beforeEach` fixture.
- We do not currently fork mainnet or testnets to run tests. This is due to the relatively simple nature of integration with external contracts at this time.
- If our integrations with external contracts become more complex in the future, we may consider forking mainnet or testnets to run tests. Alternatively, we may consider using git submodules to pull in external contracts, and run tests against those contracts.
- To improve readability, tests are written in TypeScript. Additionally, we define a few augmentations in `../augmentations.d.ts` to improve readability and type safety. For example, we use a set of named accounts (`type TestAccountsArtBlocks`) to improve readability by naming hardhat's accounts a set of commonly used roles.
Expand Down