Fixup sloppy merge

Author: Shaptic

docs/build/guides/testing/unit-tests.mdx

@@ -71,4 +71,13 @@ The `Env` created at the beginning of the test is not a simulation of the Soroba
 
 :::
 
+It's a simple test, but it's a complete 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`.
+2. Register the contract(s) to be tested.
+3. Invoke functions using a client.
+4. Assert the outcome.
+
 [increment contract]: https://github.com/stellar/soroban-examples/blob/main/increment/src/lib.rs

docs/data/rpc/api-reference/methods/getLedgerEntries.mdx

@@ -265,8 +265,6 @@ function getLedgerKeyWasmId(
 
 Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that has been deployed under the `contractId` we started out with so very long ago. This `LedgerKey` can be used in a final request to `getLedgerEntries`. In that response we will get a `LedgerEntryData` corresponding to a `ContractCodeEntry` which will contain the actual, deployed, real-life contract byte-code:
 
-<CodeExample>
-
 ```typescript
 const theHashData: xdr.ContractDataEntry = await getLedgerEntries(
   getLedgerKeyContractCode("C..."),
@@ -277,14 +275,10 @@ const theCode: Buffer = await getLedgerEntries(getLedgerKeyWasmId(theHashData))
   .code();
 ```
 
-</CodeExample>
-
 ## Actually fetching the ledger entry data
 
 Once we've learned to _build_ and _parse_ these (which we've done above at length), the process for actually fetching them is always identical. If you know the type of key you fetched, you apply the accessor method accordingly once you've received them from the `getLedgerEntries` method:
 
-<CodeExample>
-
 ```typescript
 const s = new Server("https://soroban-testnet.stellar.org");
 
@@ -296,6 +290,8 @@ const contractData = keys.entries[2].contractData();
 const contractCode = keys.entries[1].contractCode();
 ```
 
+Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that has been deployed under the `ContractId` we started out with so very long ago. This `LedgerKey` can be used in a final request to the Stellar-RPC endpoint.
+
 ```json
 {
   "jsonrpc": "2.0",
@@ -311,8 +307,6 @@ const contractCode = keys.entries[1].contractCode();
 }
 ```
 
-</CodeExample>
-
 Then you can inspect them accordingly. Each of the above entries follows the XDR for that `LedgerEntryData` structure precisely. For example, the `AccountEntry` is in [`Stellar-ledger-entries.x#L191`](https://github.com/stellar/stellar-xdr/blob/529d5176f24c73eeccfa5eba481d4e89c19b1181/Stellar-ledger-entries.x#L191) and you can use `.seqNum()` to access its current sequence number, as we've shown. In JavaScript, you can see the appropriate methods in the [type definition](https://github.com/stellar/js-stellar-base/blob/6930a70d7fbde675514b5933baff605d97453ba7/types/curr.d.ts#L3034).
 
 ## Viewing and understanding XDR