fmt

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.

docs/build/guides/testing/fuzzing.mdx

@@ -25,23 +25,23 @@ 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]
    -crate-type = ["cdylib"]
    +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]
     libfuzzer-sys = "0.4"
    +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
 

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.

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.

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.

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.