diff --git a/.changeset/wild-months-carry.md b/.changeset/wild-months-carry.md
new file mode 100644
index 0000000000000..f8d0e6074d524
--- /dev/null
+++ b/.changeset/wild-months-carry.md
@@ -0,0 +1,5 @@
+---
+'@eth-optimism/contracts-bedrock': patch
+---
+
+Document test function naming convention and create a script for checking.
diff --git a/packages/contracts-bedrock/README.md b/packages/contracts-bedrock/README.md
index ec9b9bc6ce2f2..adb00e2a22f6b 100644
--- a/packages/contracts-bedrock/README.md
+++ b/packages/contracts-bedrock/README.md
@@ -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.