Document VM testing

core/lib/multivm/README.md

@@ -4,3 +4,15 @@ This crate represents a wrapper over several versions of VM that have been used
 glue code that allows switching the VM version based on the externally provided marker while preserving the public
 interface. This crate exists to enable the external node to process breaking upgrades and re-execute all the
 transactions from the genesis block.
+
+## Developer guidelines
+
+### Adding tests
+
+If you want to add unit tests for the VM wrapper, consider the following:
+
+- Whenever possible, make tests reusable; declare test logic in the [`testonly`](src/versions/testonly/mod.rs) module,
+  and then instantiate tests using this logic for the supported VM versions. If necessary, extend the tested VM trait so
+  that test logic can be defined in a generic way. See the `testonly` module docs for more detailed guidelines.
+- Do not use an RNG where it can be avoided (e.g., for test contract addresses).
+- Avoid using zero / default values in cases they can be treated specially by the tested code.

core/lib/multivm/src/versions/testonly/mod.rs

@@ -6,6 +6,8 @@
 //!   (`vm_latest`) and the fast VM (`vm_fast`).
 //! - Submodules of this module define test functions generic by `TestedVm`. Specific VM versions implement `TestedVm`
 //!   and can create tests based on these test functions with minimum amount of boilerplate code.
+//! - Tests use [`VmTester`] built using [`VmTesterBuilder`] to create a VM instance. This allows to set up storage for the VM,
+//!   custom [`SystemEnv`] / [`L1BatchEnv`], deployed contracts, pre-funded accounts etc.
 
 use ethabi::Contract;
 use once_cell::sync::Lazy;