Apply suggestions from code review

Co-authored-by: ToriLindsay <[email protected]>

Author: penalosa

src/content/docs/workers/testing/integration-testing.mdx

@@ -108,7 +108,7 @@ try {
 
 ## [Miniflare's API](/workers/testing/miniflare/writing-tests/)
 
-If you would like to write integration tests for multiple Workers, need direct access to [bindings](/workers/runtime-apis/bindings/) outside your Worker in tests, or have another advanced use case, consider using [Miniflare's API](/workers/testing/miniflare) directly. Miniflare is the foundation for the other testing tools on this page, exposing a JavaScript API for the [`workerd` runtime](https://github.com/cloudflare/workerd) and local simulators for the other Developer Platform products. Unlike `unstable_startWorker()`, Miniflare does not automatically load options from your Wrangler configuration file. Refer to the [Writing Tests](/workers/testing/miniflare/writing-tests/) page for an example of how to use Miniflare together with `node:test`.
+If you would like to write integration tests for multiple Workers, need direct access to [bindings](/workers/runtime-apis/bindings/) outside your Worker in tests, or have another advanced use case, consider using [Miniflare's API](/workers/testing/miniflare) directly. Miniflare is the foundation for the other testing tools on this page, exposing a JavaScript API for the [`workerd` runtime](https://github.com/cloudflare/workerd) and local simulators for the other Developer Platform products. Unlike `unstable_startWorker()`, Miniflare does not automatically load options from your Wrangler configuration file. Refer to the [Writing tests](/workers/testing/miniflare/writing-tests/) page for an example of how to use Miniflare together with `node:test`.
 
 ```js
 import assert from "node:assert";

src/content/docs/workers/testing/miniflare/writing-tests.mdx

@@ -15,7 +15,7 @@ import { TabItem, Tabs, Details } from "~/components";
 
 import { FileTree } from "@astrojs/starlight/components";
 
-This guide will instruct you through setting up [Miniflare](/workers/testing/miniflare) for testing your Workers. Miniflare is a low-level API that allows you to fully control how your Workers are run and tested.
+This guide will show you how to set up [Miniflare](/workers/testing/miniflare) to test your Workers. Miniflare is a low-level API that allows you to fully control how your Workers are run and tested.
 
 To use Miniflare, make sure you've installed the latest version of Miniflare v3:
 
@@ -41,9 +41,9 @@ pnpm add -D miniflare
 
 The rest of this guide demonstrates concepts with the [`node:test`](https://nodejs.org/api/test.html) testing framework, but any testing framework can be used.
 
-Miniflare is a low-level API that exposes a large variety of configuration options for running your Worker. In most cases, your tests will only need a subset of the available options, but you can refer to the [full API reference](/workers/testing/miniflare/get-started/#reference) to explore what's possible with Miniflare.
+Miniflare is a low-level API that exposes a large variety of configuration options for running your Worker. In most cases, your tests will only need a subset of the available options, but you can refer to the [full API reference](/workers/testing/miniflare/get-started/#reference) to explore what is possible with Miniflare.
 
-Before writing a test, you'll need to create a Worker. Since Miniflare is a low-level API that emulates the Cloudflare platform primitives, your Worker will need to be written in JavaScript or you'll need to [integrate your own build pipeline](#custom-builds) into your testing setup. Here's an example JavaScript-only Worker:
+Before writing a test, you will need to create a Worker. Since Miniflare is a low-level API that emulates the Cloudflare platform primitives, your Worker will need to be written in JavaScript or you'll need to [integrate your own build pipeline](#custom-builds) into your testing setup. Here's an example JavaScript-only Worker:
 
 ```js title="src/index.js"
 export default {
@@ -53,7 +53,7 @@ export default {
 };
 ```
 
-Next, you'll need to create an initial test file:
+Next, you will need to create an initial test file:
 
 ```js {12,13,14,15,16,17,18,19} title="src/index.test.js"
 import assert from "node:assert";
@@ -93,15 +93,15 @@ describe("worker", () => {
 
 You should be able to run the above test via `node --test`
 
-The highlighted lines of the test file above demonstrate how to set up Miniflare to run a JavaScript Worker. Once Miniflare has been set up, your individual tests can send requests to the running Worker and assert against the responses. This is the main limitation of using Miniflare for testing your Worker as compared to the [Vitest integration](/workers/testing/vitest-integration/)—all access to your Worker must be through the `dispatchFetch()` Miniflare API, and you cannot unit test individual functions from your Worker.
+The highlighted lines of the test file above demonstrate how to set up Miniflare to run a JavaScript Worker. Once Miniflare has been set up, your individual tests can send requests to the running Worker and assert against the responses. This is the main limitation of using Miniflare for testing your Worker as compared to the [Vitest integration](/workers/testing/vitest-integration/) — all access to your Worker must be through the `dispatchFetch()` Miniflare API, and you cannot unit test individual functions from your Worker.
 
 <Details header="What runtime are tests running in?">
 	When using the [Vitest integration](/workers/testing/vitest-integration/),
 	your entire test suite runs in
-	[`workerd`](https://github.com/cloudflare/workerd), which is why it's possible
+	[`workerd`](https://github.com/cloudflare/workerd), which is why it is possible
 	to unit test individual functions. By contrast, when using a different testing
 	framework to run tests via Miniflare, only your Worker itself is running in
-	[`workerd`](https://github.com/cloudflare/workerd)—your test files run in
+	[`workerd`](https://github.com/cloudflare/workerd) — your test files run in
 	Node.js. This means that importing functions from your Worker into your test
 	files might exhibit different behaviour than you'd see at runtime if the
 	functions rely on `workerd`-specific behaviour.
@@ -111,7 +111,7 @@ The highlighted lines of the test file above demonstrate how to set up Miniflare
 
 :::caution
 
-Miniflare does not read [Wrangler's config file](/workers/wrangler/configuration), and so all bindings that your Worker uses need to be specified in the Miniflare API options.
+Miniflare does not read [Wrangler's config file](/workers/wrangler/configuration). All bindings that your Worker uses need to be specified in the Miniflare API options.
 
 :::
 
@@ -139,7 +139,7 @@ describe("worker", () => {
 });
 ```
 
-You can also interact with local resources such as KV and R2, using the same API as you would from a Worker. For example, here's how you would interact with a KV namespace:
+You can also interact with local resources such as KV and R2 using the same API as you would from a Worker. For example, here's how you would interact with a KV namespace:
 
 ```diff lang="js" title="src/index.test.js"
 ...
@@ -193,7 +193,7 @@ new Miniflare({
 
 ## Custom builds
 
-In many real-world cases, Workers are not written as plain JavaScript, but are instead written as multiple TypeScript files importing from npm packages etc... that are then bundled by a build tool. When testing your Worker via Miniflare directly you need to run this build tool before your tests. Exactly how this build is run will depend on the specific test framework you use, but for `node:test` it would likely be in a `setup()` hook. For example, if you use [Wrangler](/workers/wrangler/) to build and deploy your Worker, you could spawn a `wrangler build` command:
+In many real-world cases, Workers are not written in plain JavaScript but instead consist of multiple TypeScript files that import from npm packages and other dependencies, which are then bundled by a build tool. When testing your Worker via Miniflare directly you need to run this build tool before your tests. Exactly how this build is run will depend on the specific test framework you use, but for `node:test` it would likely be in a `setup()` hook. For example, if you use [Wrangler](/workers/wrangler/) to build and deploy your Worker, you could spawn a `wrangler build` command like this:
 
 ```js
 before(() => {

src/content/docs/workers/wrangler/api.mdx

@@ -18,7 +18,7 @@ Wrangler offers APIs to programmatically interact with your Cloudflare Workers.
 
 ## `unstable_startWorker`
 
-This API exposes the internals of Wrangler's dev server, and allows you to customise how it runs. For example, you could use `unstable_startWorker()` to run integration tests against your Worker (the below example is with `node:test`, but this should work in any testing framework):
+This API exposes the internals of Wrangler's dev server, and allows you to customise how it runs. For example, you could use `unstable_startWorker()` to run integration tests against your Worker. This example uses `node:test`, but should apply to any testing framework:
 
 ```js
 import assert from "node:assert";