Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
N
nebula
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
exchain
nebula
Commits
7300a7ca
Unverified
Commit
7300a7ca
authored
Dec 02, 2022
by
Maurelian
Committed by
GitHub
Dec 02, 2022
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
docs(ctb): Document the testing conventions (#4122)
parent
7768eddb
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
50 additions
and
0 deletions
+50
-0
wild-months-carry.md
.changeset/wild-months-carry.md
+5
-0
README.md
packages/contracts-bedrock/README.md
+45
-0
No files found.
.changeset/wild-months-carry.md
0 → 100644
View file @
7300a7ca
---
'
@eth-optimism/contracts-bedrock'
:
patch
---
Document test function naming convention and create a script for checking.
packages/contracts-bedrock/README.md
View file @
7300a7ca
...
...
@@ -194,3 +194,48 @@ After the initial Bedrock upgrade, contracts MUST use the following versioning s
#### Exceptions
We have made an exception to the
`Semver`
rule for the
`WETH`
contract to avoid making changes to a well-known, simple, and recognizable contract.
### Tests
Tests are written using Foundry.
All test contracts and functions should be organized and named according to the following guidelines.
These guidelines are also encoded in a script which can be run with:
```
ts-node scripts/forge-test-names.ts
```
*Note: This is a work in progress, not all test files are compliant with these guidelines.*
#### Organizing Principles
-
Solidity
`contract`
s are used to organize the test suite similar to how mocha uses describe.
-
Every non-trivial state changing function should have a separate contract for happy and sad path
tests. This helps to make it very obvious where there are not yet sad path tests.
-
Simpler functions like getters and setters are grouped together into test contracts.
#### Test function naming convention
Test function names are split by underscores, into 3 or 4 parts. An example function name is
`test_onlyOwner_callerIsNotOwner_reverts()`
.
The parts are:
`[method]_[FunctionName]_[reason]_[success]`
, where:
-
`[method]`
is either
`test`
,
`testFuzz`
, or
`testDiff`
-
`[FunctionName]`
is the name of the function or higher level behavior being tested.
-
`[reason]`
is an optional description for the behavior being tested.
-
`[status]`
must be one of:
-
`succeeds`
: used for most happy path cases
-
`reverts`
: used for most sad path cases
-
`works`
: used for tests which include a mix of happy and sad assertions (these should be broken up if possible)
-
`fails`
: used for tests which 'fail' in some way other than reverting
-
`benchmark`
: used for tests intended to establish gas costs
#### Contract Naming Conventions
Test contracts should be named one of the following according to their use:
-
`TargetContract_Init`
for contracts that perform basic setup to be reused in other test contracts.
-
`TargetContract_Function_Test`
for contracts containing happy path tests for a given function.
-
`TargetContract_Function_TestFail`
for contracts containing sad path tests for a given function.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment