Hey there @ianbrtt!
I see that since you were working on this a little bit has changed for us in terms of testing. We've released openzeppelin-test-helpers and migrated the test suite to use that package.
People had been using our helpers informally for a long time, so we decided to make them a proper package. The helpers are basically the same than the ones we had before, though we've been improving them at a faster pace now.
Another big difference is that the helpers have their own documentation now. Any doubts you have about the helpers themselves should be explained in that reference, and if they aren't explained please open an issue or a pull request.
What I think we're missing is a self-contained guide/tutorial on "how OpenZeppelin tests its smart contracts", that can help people test their own contracts or contribute to OpenZeppelin. If you'd like to continue working on this guide, we think that this should be the focus.
We put together some points that describe how a contract's tests are usually structured:
-
Top level
its that test the ways the constructor can revert. -
A main top level
contextto test all functionality.- A
beforeEachblock that deploys the contract. - Tests for the simple view functions.
- A
describeblock for each "big feature" of the contract.- A test for each way an argument can be wrong (seeing the
requires in the code). - Tests for the happy paths. If there is a common setup step for several tests, group them in a
describeblock and add the setup inbeforeEach. Make sure to test edge cases.
- A test for each way an argument can be wrong (seeing the
- A
-
Potentially a few other
contexts to test some functionality with edge cases in the constructor parameters. (For example, aPaymentSplitterwith a single payee.) -
All of the above has to be done by reading the source or the spec if available.
Ideally what we want is a guide describing this in a bit more detail, and pointing out examples in the repository. In some cases it could be a good idea to point out helpers that might be useful.