Update tutorial docs spelling

Author: ostenbom

tutorial/stage-0-baseline/playwright-e2e-from-cowboy-to-confidence.mdx

@@ -1,6 +1,6 @@
 ---
 title: Playwright e2e testing - from cowboy to confidence
-description: Outline of the Endform saas tutorial, where we will take an untested saas application and build a Playwright test suite for it.
+description: Outline of the Endform SaaS tutorial, where we will take an untested SaaS application and build a Playwright test suite for it.
 sidebar:
   order: 1
 ---
@@ -15,18 +15,18 @@ _Maybe you're a bit of a cowboy._
 
 Maybe you already have unit and integration tests, but you still keep running through user flows manually in your browser.
 
-Or you're a more seasoned Playwright tester, but you're looking to brush up on the latest and greatest, and improve your setup. 
+Or you're a more seasoned Playwright tester, but you're looking to brush up on the latest and greatest, and improve your setup.
 
-In this tutorial, we will end-to-end test a realistic software as a service application from scratch.
-We will cover all of the Playwright features that you need to be productive in your day to day.
+In this tutorial, we will end-to-end test a realistic software-as-a-service application from scratch.
+We will cover all of the Playwright features that you need to be productive in your day-to-day work.
 
 So come along, and let's get you from cowboy to confidence.
 
 ## Source code
 
-The full repository for this tutorial can be found [here](https://github.com/endformdev/playwright-tutorial). 
+The full repository for this tutorial can be found [here](https://github.com/endformdev/playwright-tutorial).
 
-The repository contains a software as a service application that has login, logout, user modification, team management and checkout functionality.
+The repository contains a software-as-a-service application that has login, logout, user modification, team management, and checkout functionality.
 The application is built with Next.js and can either be run locally from your command line or you can test against our [pre-deployed version of it](https://endform-playwright-tutorial.vercel.app).
 
 ## Getting started with the tutorial repository
@@ -36,7 +36,7 @@ To get started, you will need to:
 - [Clone the repository](https://github.com/endformdev/playwright-tutorial): `git clone https://github.com/endformdev/playwright-tutorial && cd playwright-tutorial`
 - Make sure you have [`pnpm` installed on your system](https://pnpm.io/installation#using-corepack)
 - Install the dependencies: `pnpm install`
-- Checkout the branch for the stage you want to start from, for example: `git checkout stage-0-baseline`
+- Check out the branch for the stage you want to start from, for example: `git checkout stage-0-baseline`
 
 We will be testing against a realistic dummy application.
 You can either:
@@ -53,12 +53,12 @@ You can either:
 ## Choose where to start
 
 Each step of the tutorial has a [branch associated with it](https://github.com/endformdev/playwright-tutorial/branches), with all of the work included from the previous tutorial steps.
-You can choose to start from the beginning, or you can start from a specific step, depending on what you're interested in and what your previous experience with Playwright is. 
+You can choose to start from the beginning, or you can start from a specific step, depending on what you're interested in and what your previous experience with Playwright is.
 
 Here's what we'll cover in each step:
 
 <LinkCard
-  title="Practical playwright setup"
+  title="Practical Playwright setup"
   description="Setting up a Playwright project to make your future testing life easier."
   href="/docs/tutorial/practical-playwright-setup"
 />
@@ -81,4 +81,3 @@ Here's what we'll cover in each step:
   href="/docs/tutorial/understanding-test-results"
 />
 
-

tutorial/stage-1-setup/practical-playwright-setup.mdx

@@ -9,7 +9,7 @@ import { Aside, Tabs, TabItem } from '@astrojs/starlight/components';
 import { Image } from "astro:assets";
 import StepOverDebug from "../../../assets/step-over-debug.png";
 
-In this part of the tutorial, we will both set up a Playwright project from scratch, but we will also learn to use the most important features to be more productive with Playwright when using a real-world application.
+In this part of the tutorial, we will set up a Playwright project from scratch and learn to use the most important features for being more productive with Playwright in a real-world application.
 
 Some Playwright features we will cover include:
 
@@ -20,7 +20,7 @@ Some Playwright features we will cover include:
 Let's get started!
 
 <Aside>
-To start from this step, checkout the [`stage-0-baseline` branch](https://github.com/endformdev/playwright-tutorial/tree/stage-0-baseline) of the [tutorial repository](https://github.com/endformdev/playwright-tutorial).
+To start from this step, check out the [`stage-0-baseline` branch](https://github.com/endformdev/playwright-tutorial/tree/stage-0-baseline) of the [tutorial repository](https://github.com/endformdev/playwright-tutorial).
 For more information about getting started with the tutorial repository, go [here](/docs/tutorial/playwright-e2e-from-cowboy-to-confidence#getting-started-with-the-tutorial-repository).
 </Aside>
 
@@ -62,7 +62,7 @@ projects: [
 		name: "chromium",
 		use: { ...devices["Desktop Chrome"] },
 	}
-  // Remove the other firefox and webkit projects
+  // Remove the other Firefox and WebKit projects
 ]
 ```
 
@@ -71,7 +71,7 @@ projects: [
 Let's check that this works by modifying the `example.spec.ts` test file in the `tests` directory.
 
 - Remove the second test "get started link"
-- Modify the first test to go to the default url `await page.goto("/")`
+- Modify the first test to go to the default URL `await page.goto("/")`
 - Modify the expectation to check for our page title `/Playwright Tutorial/`
 - Watch your test run `pnpm playwright test --debug`
 
@@ -80,7 +80,7 @@ When you run Playwright in debug mode for the first time, the browser will open
 </Aside>
 
 You can watch your test step by step by using the "step over" button.
-<Image src={StepOverDebug} alt="Step over button in Playwrights inspector" width={600} />
+<Image src={StepOverDebug} alt="Step over button in Playwright's inspector" width={600} />
 
 ## Alternatives for creating temporary test data (like users)
 
@@ -89,20 +89,20 @@ Almost all of the tests that you will end up making will require some amount of
 There are two schools of thought about how to create this test data.
 Either you can create it by using the browser and clicking through your application to create that data, or you can use either your public API or create internal APIs in order to create this data more efficiently.
 
-Playwright has two methods of globally setting up test data before your suite runs. Project dependencies, which runs a browser, or global setup, which is more like a simple script more suited to API calls.
+Playwright has two methods of globally setting up test data before your suite runs: project dependencies, which run a browser, or global setup, which is more like a simple script better suited to API calls.
 
-If we look at [Playwrights documentation](https://playwright.dev/docs/test-global-setup-teardown), we can see that it slightly prefers using project dependencies to globally set up and tear down test data.
-The table in the documentation there outlines how using project dependencies provides more visibility into how the set up and tear down steps work.
+If we look at [Playwright's documentation](https://playwright.dev/docs/test-global-setup-teardown), we can see that it slightly prefers using project dependencies to globally set up and tear down test data.
+The table in the documentation there outlines how using project dependencies provides more visibility into how the setup and teardown steps work.
 
 In our experience, having an API endpoint available to create data (like test users), instead of requiring a whole browser, makes your Playwright project more flexible long term.
 Initially you will feel like one user is enough, in which case the browser-based setup method is the simplest.
 However, further down the line, you will likely need to make several users, some for cases where users collide such as your "delete user" flow.
 When this happens, you will find that your API endpoints will make it much easier to create these tests.
 
-If you learn to create and use API endpoints like this, it will be much easier for you to extend them to create more kinds of useful test data, such as organisations or organisation memberships.
-This will really take your ability to test end to end test your application to a whole new level.
+If you learn to create and use API endpoints like this, it will be much easier for you to extend them to create more kinds of useful test data, such as organizations or organization memberships.
+This will really take your ability to test your application end-to-end to a whole new level.
 
-Today we will learn to use both kinds of set up approaches.
+Today we will learn to use both kinds of setup approaches.
 
 ### Setup & teardown with Playwright project dependencies
 
@@ -171,7 +171,7 @@ export default defineConfig({
 </TabItem>
 </Tabs>
 
-We'll talk more about generating tests in the next step, so here's the completed setup / teardonwn and modified example tests to copy for now.
+We'll talk more about generating tests in the next step, so here's the completed setup / teardown and modified example tests to copy for now.
 
 
 <Tabs>
@@ -299,7 +299,7 @@ export default defineConfig({
 
 ### Creating / deleting users through an API
 
-Let's explore the alternative to creating users through the browser, which is to create and use API endpoints for our test data. 
+Let's explore the alternative to creating users through the browser, which is to create and use API endpoints for our test data.
 
 Let's make ourselves an internal API endpoint for our tests to use.
 
@@ -338,7 +338,7 @@ export async function DELETE(request: Request) {
 }
 ```
 
-Let's set up a global setup and global teardown script to use these API endpoints. 
+Let's set up a global setup and global teardown script to use these API endpoints.
 First we need to modify the `playwright.config.ts` file.
 
 ```ts
@@ -524,10 +524,10 @@ export default defineConfig({
 
 ## Wrapping up
 
-At this point in time, we don't just have a basic playwright project set up, but we have a very practical playwright set up for our future testing needs. 
+At this point, we don't just have a basic Playwright project set up, but we have a very practical Playwright setup for our future testing needs.
 
 We have:
 
-- A file structure and config file for running a Playwright suite in typescript
+- A file structure and config file for running a Playwright suite in TypeScript
 - A set of projects that depend on each other where we can create shared test data
-- API endpoints for easily creating more test data when needed
+- API endpoints for easily creating more test data when needed

tutorial/stage-2-generated-tests/generate-tests-playwright-mcp.mdx

@@ -12,7 +12,7 @@ import CursorActivityTodo from "../../../assets/cursor-activity-todo.png";
 In this guide, we will use the Playwright MCP to generate tests for your application.
 
 <Aside>
-To start from this step, checkout the [`stage-1-setup` branch](https://github.com/endformdev/playwright-tutorial/tree/stage-1-setup) of the [tutorial repository](https://github.com/endformdev/playwright-tutorial).
+To start from this step, check out the [`stage-1-setup` branch](https://github.com/endformdev/playwright-tutorial/tree/stage-1-setup) of the [tutorial repository](https://github.com/endformdev/playwright-tutorial).
 For more information about getting started with the tutorial repository, go [here](/docs/tutorial/playwright-e2e-from-cowboy-to-confidence#getting-started-with-the-tutorial-repository).
 </Aside>
 
@@ -41,7 +41,7 @@ For example for Cursor, your `mcp.json` file could look like this:
 
 ## Authenticating with the Playwright MCP Server
 
-At the time of writing, the Playwright MCP server doesn't have support for the projects or storage states that we set up in our Playwright config in the previous step. 
+At the time of writing, the Playwright MCP server doesn't have support for the projects or storage states that we set up in our Playwright config in the previous step.
 
 You can achieve something similar by using the following flags to the MCP server:
 
@@ -431,14 +431,14 @@ Other classic problems with the tests that the AI generated:
 
 - Strict mode violations / more than one element on the page that matches a locator
 - Adding manual timeouts to tests instead of crafting good assertions
-- Hardcoding urls instead of using relative paths
-- Not using Playwright `test.step` to label steps in the test & excessive comments
+- Hardcoding URLs instead of using relative paths
+- Not using Playwright `test.step` to label steps in the test and using excessive comments
 
 ## Areas for improvement for our test setup at the moment
 
 It's been fantastic to generate a few tests using this method.
-When creating this tutorial, I was able to go from one test to ten tests in the space of just an hour or two, but that also should give us a little space to reflect over what we've done.
+When creating this tutorial, I was able to go from one test to ten tests in the space of just an hour or two, but that should also give us a little space to reflect on what we've done.
 
 At the moment:
 
-- Have lots of duplicated selectors in tests where better practice would be to have [page object models](https://playwright.dev/docs/pom) so that we can reduce the amount of places we need to update selectors when changes are needed.
+- We have lots of duplicated selectors in tests where better practice would be to have [page object models](https://playwright.dev/docs/pom), so that we can reduce the number of places we need to update selectors when changes are needed.

tutorial/stage-3-endform-integration/speeding-up-with-endform.mdx

@@ -1,6 +1,6 @@
 ---
 title: Speeding up with Endform
-description: Use endform to speed up your test suite.
+description: Use Endform to speed up your test suite.
 sidebar:
   order: 4
 ---
@@ -9,17 +9,17 @@ import { Aside, Tabs, TabItem } from '@astrojs/starlight/components';
 import { Image } from "astro:assets";
 import TestTimeChart from "../../../assets/test-time-chart.png";
 
-In this guide, we will use endform to speed up your test suite.
+In this guide, we will use Endform to speed up your test suite.
 
 <Aside>
-To start from this step, checkout the [`stage-2-generated-tests` branch](https://github.com/endformdev/playwright-tutorial/tree/stage-2-generated-tests) of the [tutorial repository](https://github.com/endformdev/playwright-tutorial).
+To start from this step, check out the [`stage-2-generated-tests` branch](https://github.com/endformdev/playwright-tutorial/tree/stage-2-generated-tests) of the [tutorial repository](https://github.com/endformdev/playwright-tutorial).
 For more information about getting started with the tutorial repository, go [here](/docs/tutorial/playwright-e2e-from-cowboy-to-confidence#getting-started-with-the-tutorial-repository).
 </Aside>
 
-At this point in time, we have a pretty decent Playwriht end to end testing suite that can test most of the dummy features in this application.
-We can test complex multi user flows like inviting, and we have the ability to create new users on demand when the user data conflicts with other tests.
+At this point, we have a pretty decent Playwright end-to-end testing suite that can test most of the dummy features in this application.
+We can test complex multi-user flows like inviting, and we have the ability to create new users on demand when the user data conflicts with other tests.
 
-Since this a very simple application, our tests are thankfully very fast to run. Let's explore their performance.
+Since this is a very simple application, our tests are thankfully very fast to run. Let's explore their performance.
 
 ## Running the tests
 
@@ -35,9 +35,9 @@ Let's try running the tests with Endform also to get a benchmark:
 pnpm endform test
 ```
 
-On my machine (M2 Macbook Pro), the tests ran in 20 seconds with Playwright, and 25 seconds with Endform.
+On my machine (M2 MacBook Pro), the tests ran in 20 seconds with Playwright and 25 seconds with Endform.
 
-With these very fast, very small, and few tests - uploading and running the tests on Endform's remote runners aren't giving us much of a speedup.
+With these few, very fast tests, uploading and running the tests on Endform's remote runners isn't giving us much of a speedup.
 
 ## Cranking up the heat
 
@@ -72,13 +72,12 @@ while Endform will keep the speed constant.
 
 ### Other influential factors
 
-This is one case of the speed of this particular suite, but lots of things have an impact on the speed of a suite.
-Like:
+This is one case of the speed of this particular suite, but lots of things have an impact on suite speed, including:
 
 - How reliable or flaky the tests are
 - How long the tests take to run
 - How slow the slowest test is
-- How performant the app the tests are run against is
+- How performant the app under test is
 
 We think that we have the fastest Playwright test runner on the market, but we're really curious to hear what your experience in running Endform versus Playwright in your test suite is like.
 
@@ -126,8 +125,8 @@ jobs:
 
 Here we used the [`repository_dispatch` event](https://vercel.com/docs/git/vercel-for-github#repository-dispatch-events) to trigger the workflow when the Vercel deployment is successful.
 
-Some other thigns you could try are:
+Some other things you could try are:
 
 - Just trigger on commits to the main branch
 - Triggering on pull requests
-- Sending a message to a Slack channel when the tests are successful or fail
+- Sending a message to a Slack channel when the tests are successful or fail