diff --git a/docs/build/guides/testing/differential-tests.mdx b/docs/build/guides/testing/differential-tests.mdx
index 0bc14b371..945087113 100644
--- a/docs/build/guides/testing/differential-tests.mdx
+++ b/docs/build/guides/testing/differential-tests.mdx
@@ -83,6 +83,7 @@ Assuming the contract has been deployed, and changes are being made to the local
 3. Run the test to compare the baseline and local observable outcomes.
 
 This test uses the same patterns used in [unit tests] and [integration tests]:
+
 1. Create an environment, the `Env`.
 2. Import the Wasm contract to compare with.
 3. Register the local contract to be tested.
diff --git a/docs/build/guides/testing/fuzzing.mdx b/docs/build/guides/testing/fuzzing.mdx
index 485d9badb..9a5ddd8df 100644
--- a/docs/build/guides/testing/fuzzing.mdx
+++ b/docs/build/guides/testing/fuzzing.mdx
@@ -25,7 +25,7 @@ The following steps can be used in any Stellar contract workspace. If experiment
    $ cargo fuzz init
    ```
 
-2. Open the contract's `Cargo.toml` file. Add `lib` as a `crate-type`.
+3. Open the contract's `Cargo.toml` file. Add `lib` as a `crate-type`.
 
    ```diff
     [lib]
@@ -33,7 +33,7 @@ The following steps can be used in any Stellar contract workspace. If experiment
    +crate-type = ["lib", "cdylib"]
    ```
 
-2. Open the generated `fuzz/Cargo.toml` file. Add the `soroban-sdk` dependency.
+4. Open the generated `fuzz/Cargo.toml` file. Add the `soroban-sdk` dependency.
 
    ```diff
     [dependencies]
@@ -41,7 +41,7 @@ The following steps can be used in any Stellar contract workspace. If experiment
    +soroban-sdk = { version = "*", features = ["testutils"] }
    ```
 
-3. Open the generated `fuzz/src/fuzz_target_1.rs` file. It will look like the below.
+5. Open the generated `fuzz/src/fuzz_target_1.rs` file. It will look like the below.
 
    ```rust
    #![no_main]
@@ -52,7 +52,7 @@ The following steps can be used in any Stellar contract workspace. If experiment
    });
    ```
 
-4. Fill out the `fuzz_target!` call with test setup and assertions. For example, for the [increment example]:
+6. Fill out the `fuzz_target!` call with test setup and assertions. For example, for the [increment example]:
 
    ```rust
    #![no_main]
@@ -85,7 +85,7 @@ The following steps can be used in any Stellar contract workspace. If experiment
    });
    ```
 
-5. Execute the fuzz target.
+7. Execute the fuzz target.
 
    ```
    cargo +nightly fuzz run --sanitizer=thread fuzz_target_1
@@ -98,10 +98,11 @@ The following steps can be used in any Stellar contract workspace. If experiment
    :::
 
 This test uses the same patterns used in [unit tests] and [integration tests]:
+
 1. Create an environment, the `Env`.
-3. Register the contract to be tested.
-4. Invoke functions using a client.
-5. Assert expectations.
+2. Register the contract to be tested.
+3. Invoke functions using a client.
+4. Assert expectations.
 
 :::tip
 
diff --git a/docs/build/guides/testing/integration-tests.mdx b/docs/build/guides/testing/integration-tests.mdx
index e9363bf10..d8bfaaf3d 100644
--- a/docs/build/guides/testing/integration-tests.mdx
+++ b/docs/build/guides/testing/integration-tests.mdx
@@ -59,6 +59,7 @@ fn test() {
 ```
 
 Most tests, whether they're unit, mocks, or integration tests, will look very similar to the test above. The tests will do four things:
+
 1. Create an environment, the `Env`.
 2. Register the contract(s) to be tested.
 3. Invoke functions using the generated client.
diff --git a/docs/build/guides/testing/mocking.mdx b/docs/build/guides/testing/mocking.mdx
index 6245a5c03..67de17c4b 100644
--- a/docs/build/guides/testing/mocking.mdx
+++ b/docs/build/guides/testing/mocking.mdx
@@ -59,6 +59,7 @@ fn test_notpaused() {
 ```
 
 The following test checks that when the pause contract is paused, the increment contract function rejects attempts to increment.
+
 ```rust
 #![cfg(test)]
 use crate::{Error, IncrementContract, IncrementContractArgs, IncrementContractClient, Pause};
@@ -95,6 +96,7 @@ fn test_paused() {
 ```
 
 Most tests, whether you're writing unit, mocks, or integration tests, will look very similar to these tests. They'll do four things:
+
 1. Create an environment, the `Env`.
 2. Register the contract(s) to be tested.
 3. Invoke functions using the generated client.
diff --git a/docs/build/guides/testing/test-with-mainnet-data.mdx b/docs/build/guides/testing/test-with-mainnet-data.mdx
index 9be6c086c..6a7e18f91 100644
--- a/docs/build/guides/testing/test-with-mainnet-data.mdx
+++ b/docs/build/guides/testing/test-with-mainnet-data.mdx
@@ -64,6 +64,7 @@ fn test() {
 ```
 
 Most tests, whether they're unit, mocks, or integration tests, will look very similar to the test above. The tests will do four things:
+
 1. Create an environment, the `Env`.
 2. Register the contract(s) to be tested.
 3. Invoke functions using the generated client.
diff --git a/docs/build/guides/testing/unit-tests.mdx b/docs/build/guides/testing/unit-tests.mdx
index b8b988cfe..7626b152f 100644
--- a/docs/build/guides/testing/unit-tests.mdx
+++ b/docs/build/guides/testing/unit-tests.mdx
@@ -33,6 +33,7 @@ Ref: https://github.com/stellar/soroban-examples/blob/main/increment/src/test.rs
 In the test there's a full environment setup, used, and torn down in the test, and it happens fast. The Rust test harness runs all the tests for a contract in parallel and each will have its own isolated contract environment.
 
 Most tests, even integration tests and fuzz tests, will look very similar to this unit test. They'll do four things:
+
 1. Create an environment, the `Env`.
 
    ```rust
@@ -58,7 +59,6 @@ Most tests, even integration tests and fuzz tests, will look very similar to thi
    assert_eq!(client.increment(), 1);
    ```
 
-
 :::tip
 
 Tests are written in Rust, alongside the contract. Same tools. Same APIs. Same SDK. No context switching! Use your favorite Rust tools and libraries that you'd use for any Rust test.