- here we build smart contracts to support our little Vault project
- we slightly change requirements, we inject any
ERC20contract for ease of development- then easy to hardcode
WETHaddress when deploying
- then easy to hardcode
- we also support faucet for our token for easier testing (hence
Faucet.solcontract), BUT only for testing purposes, we remove this by feature flag in theweb/in prod env- note: we haven't deployed and tested on mainnet...
- contracts in
contracts/folder, more details below
- built using
hardhatframework- enables running tests
- enables running local node
- enables
console.login contracts that is no-op in prod deployments - has a ton of helpers like
ignitefor deployment - all in all good ecosystem
- we use TDD unless backward incompatible etc. but goal of having each FEATURE covered by test scenarios is 99% done either way (more details in Testing Strategy below)
- since we are highly focused on tested code, even mostly doing TDD, we think few explainer lines about our testing strategy is in order
- for each FEATURE (loosely defined) we have try types of tests:
- happy paths
- edge cases
- mutliple interactions with multiple addresses (solidity specific)
- we also like th conceopt of
scenario-testsbut didnt have time to finish that here- main idea: simulate random paths with multiple addresses, that simulate realistic contract usage
- since randomized, can emulate various scenarios happening
- we have a set of INVARIANTS we check after each random step
- this way the longer it runs, the more sure we are contract won't come into illegal state
- this is low-hanging fruit method, without going into formal proofs let's say, to have a safety net
- we left work in progress, so we might discuss or finish in the potential next step
- main idea: simulate random paths with multiple addresses, that simulate realistic contract usage
- at the bottom of sub-chapter we have partial/shortened output of
tree -L 2 .command- this can help us visualize the structure
- we will explain some of the most important folders and files below
- most of the structure self-explanatory, so we will focus only on things not obvious from the structure or naming, as well as some additional notes if such
- as noted,
contracts/folder contains our main solidity logic- the only contract that is truely deliverable of this project is
OpynVault.sol - other contracts for testing purposes, except
SafeMathwhich we manually imported rather than via@openzepelin/...as other ones
- the only contract that is truely deliverable of this project is
- folder
tests/- notice that we have the numbered so we know the order of added features when using TDD
- also notice that accompanying each
.sol.jsis.txtfile which briefly outlines the test cases contained within test suite- this can be say good communication tool without need to dwelve into code or tests, sort of auto-documenting haha
├── ...
├── artifacts
├── contracts
│ ├── OpynVault.sol
│ ├── SafeMath.sol
├── hardhat.config.js
└── test
├── 1.0.OpynVaultInitialitization.spec.txt
├── 1.1.OpynVaultInitialization.spec.js
├── ...
└── ...
- in the context of this part of project, running means running tests and they all should pass
- we do two variants
- pure testing from compiled
.solartefacts and usualhardhattesting approach - but also with
localhost:8545node running and our contracts deployed- this way we also check
ignitionmodules are in ok
- this way we also check
- pure testing from compiled
yarn build:f
yarn test
- below is sample GREEN run run on our local setup
