spelling and api ref fix

Author: egil

docs/docs/getting-started/create-test-project.md

@@ -5,9 +5,9 @@ title: Creating a new bUnit Test Project
 
 # Creating a new bUnit Test Project
 
-Before you can write any tests, you need a place to put them - a test project. bUnit is not a unit test runner, so you need a general purpose test framework, like xUnit, NUnit, or MSTest, in addition to bUnit, to run your tests, and write your assertions. 
+Before you can write any tests, you need a place to put them - a test project. bUnit is not a unit test runner, so you need a general-purpose test framework, like xUnit, NUnit, or MSTest, in addition to bUnit, to run your tests, and write your assertions. 
 
-If you prefer xUnit, you can use the bUnit project template approached described in the [Create a test project with bUnit template](#create-a-test-project-with-bunit-template) section further down the page. If you want to use another general purpose testing framework, read the following section.
+If you prefer xUnit, you can use the bUnit project template approached described in the [Create a test project with bUnit template](#create-a-test-project-with-bunit-template) section further down the page. If you want to use another general-purpose testing framework, read the following section.
 
 ## Create a Test Project Manually
 
@@ -22,7 +22,7 @@ These steps look like this from the `dotnet` CLI:
 
 **1. Create a new test project**
 
-Use the following command (click on the tab that for the test framework you would like to use):
+Use the following command (_click on the tab that for the test framework you would like to use_):
 
 # [xUnit](#tab/xunit)
 
@@ -78,7 +78,7 @@ dotnet add package bunit.web --version #{VERSION}#
 
 Then you need to change a few project settings, in particular we need to change the project's SDK to `Microsoft.NET.Sdk.Razor`, remember to set `RazorLangVersion` to `3.0`,  and set the `<TargetFramework>` to `netcoreapp3.1`, since bUnit builds on `.netstandard 2.1`.
 
-To do so, change the first part of the test project's `.csproj` file to look like this.:
+To do so, change the first part of the test projects `.csproj` file to look like this.:
 
 ```xml
 <Project Sdk="Microsoft.NET.Sdk.Razor">
@@ -102,7 +102,7 @@ dotnet sln <NAME OF PROJECT>.sln add <NAME OF TEST PROJECT>
 dotnet add <NAME OF COMPONENT PROJECT>.csproj reference <NAME OF TEST PROJECT>.csproj
 ```
 
-The end result should be a test project with a `.csproj` that looks like this (other packages than bUnit might have different version numbers):
+The result should be a test project with a `.csproj` that looks like this (other packages than bUnit might have different version numbers):
 
 
 # [xUnit](#tab/xunit)
@@ -185,7 +185,7 @@ The end result should be a test project with a `.csproj` that looks like this (o
 
 ## Create a Test Project with bUnit Template
 
-If you want to skip a few steps in the guide above, you can use the [bUnit test project template](https://www.nuget.org/packages/bunit.template/). The bUNit project template is only available for using with xUnit as the general purpose testing framework, but that will change in the future.
+If you want to skip a few steps in the guide above, you can use the [bUnit test project template](https://www.nuget.org/packages/bunit.template/). The bUnit project template is only available for using with xUnit as the general-purpose testing framework, but that will change in the future.
 
 The steps are as follows:
 
@@ -225,6 +225,6 @@ dotnet add <NAME OF COMPONENT PROJECT>.csproj reference <NAME OF TEST PROJECT>.c
 
 ## Further Reading
 
-Now you are ready to write some times. To learn how, continue reading the <xref:writing-csharp-tests> and <xref:writing-razor-tests> pages.
+Now you are ready to write some tests. To learn how, continue reading the <xref:writing-csharp-tests> and <xref:writing-razor-tests> pages.
 
 For addition tips and tricks that will make writing tests easier, see the <xref:misc-test-tips> page.

docs/docs/getting-started/fixture-options.md

@@ -5,25 +5,25 @@ title: Fixture options in Razor Tests
 
 # `<Fixture>` options in Razor Tests
 
-bUnit's <xref:Bunit.Fixture> component provides different parameters you can set on it, that changes the behavior of the test. It also allow you to both set up a component under test, and additional fragments, that can be used in the test.
+bUnit's <xref:Bunit.Fixture> component provides different parameters you can set on it, that changes the behavior of the test. It also allows you to both set up a component under test, and additional fragments, that can be used in the test.
 
 
 ## Parameters
 
-All the parameters the `<Fixture>` support are shown in the listen below:
+All the parameters the `<Fixture>` support is shown in the listing below:
 
 [!code-html[](../../samples/tests/razor/AllFixtureParameters.razor)]
 
 **Setup and Test methods:**
 
-Let's start by looking at the parameters that takes a method as input first. The methods are called in the order they are listed in below, if provided, and should be used to the following:
+Let us start by looking at the parameters that takes a method as input first. The methods are called in the order they are listed in below, if provided, and should be used to the following:
 
 1. **<xref:Bunit.RazorTesting.FixtureBase`1.Setup>** and **<xref:Bunit.RazorTesting.FixtureBase`1.SetupAsync>:**  
    The `Setup` and `SetupAsync` method is called first, and you can provide both if needed. If both are provided, `Setup` is called first.   
   They allows you to configures e.g. the <xref:Bunit.ITestContext.Services> collection of the <xref:Bunit.Fixture> component before the component under test or any fragments are rendered.
 2. **<xref:Bunit.RazorTesting.FixtureBase`1.Test>** or **<xref:Bunit.RazorTesting.FixtureBase`1.TestAsync>:**  
   The `Test` or `TestAsync` methods are called after the setup methods.   
-  _One, and only one,_ of the test methods must be specified. Use the test method to access the component under test and any fragments defined in the fixture, and interact and assert against them.
+  _One, and only one,_ of the test methods must be specified. Use the test method to access the component under test and any fragments defined in the fixture and interact and assert against them.
 
 **Other parameters**
 

docs/docs/getting-started/writing-csharp-tests.md

@@ -5,15 +5,15 @@ title: Writing Tests in C# for Blazor Components
 
 # Writing Tests in C# for Blazor Components
 
-Testing Blazor components is a different from testing regular C# classes: Blazor components are *rendered*, they have the *Blazor component life-cycle*, during which we can *provide input* to them and where they *produce output*.
+Testing Blazor components is a different from testing regular C# classes: Blazor components are *rendered*, they have the *Blazor component life cycle*, during which we can *provide input* to them and where they *produce output*.
 
 **bUnit** enables you to render the component you want to test, pass in parameters to it, inject services into it, and access the rendered component instance and the markup it has produced.
 
 Rendering a component happens through bUnit's <xref:Bunit.TestContext>, and the result of the rendering, a <xref:Bunit.IRenderedComponent`1>, provides access to the component instance, and the markup produced by the component.
 
 ## Creating a Basic Test
 
-Lets see a simple example, where we test the following `<HelloWorld>` component:
+Let us see a simple example, where we test the following `<HelloWorld>` component:
 
 [!code-html[HelloWorld.razor](../../samples/components/HelloWorld.razor)]
 

docs/docs/getting-started/writing-razor-tests.md

@@ -8,7 +8,7 @@ title: Writing Tests in Razor Syntax for Blazor Components
 > [!WARNING]
 > Razor tests are currently only compatible with using xUnit as the general purpose testing framework.
 
-A test for a Blazor component can be written in a Blazor component, using a mix of Razor and C# syntax. The advantage of this is the familiarity in declaring the component under test, and other HTML or Razor fragments that will be used in the test, in Razor and HTML markup. This is especially useful when testing components that takes a lot of parameters and child content as input.
+A test for a Blazor component can be written in a Blazor component, using a mix of Razor and C# syntax. The advantage of this is the familiarity in declaring the component under test, and other HTML or Razor fragments that will be used in the test, _in Razor and HTML markup_. This is especially useful when testing components that takes a lot of parameters and child content as input.
 
 > [!INFO]
 > Tests declared inside Blazor test components can be discovered and invoked individually, and will show up in e.g. Visual Studio's Test Explorer. 
@@ -17,15 +17,15 @@ A test for a Blazor component can be written in a Blazor component, using a mix
 
 ## Create a Test Specific `_Imports.razor` File
 
-Razor tests are written in Blazor test components. To make our life's a little easier, let's first set up a `_Imports.razor` file, with the using statements we are going to be using throughout our tests. Simply add the following `_Imports.razor` to the root folder where you will be placing your Blazor test components:
+Razor tests are written in Blazor test components. To make our life's a little easier, let us first set up a `_Imports.razor` file, with the using statements we are going to be using throughout our tests. Simply add the following `_Imports.razor` to the root folder where you will be placing your Blazor test components:
 
 [!code-html[_Imports.razor](../../samples/tests/razor/_Imports.razor#L3-)]
 
 With that created, we are ready to create our first Razor test.
 
 ## Creating a Blazor Test Component
 
-A Blazor test component is conceptually very similar to a regular test class in e.g. xUnit or NUnit. You can define multiple tests inside a single test component, but those has to based on the special bUnit test components, currently either <xref:Bunit.Fixture> or <xref:Bunit.SnapshotTest>. 
+A Blazor test component is conceptually very similar to a regular test class in e.g. xUnit or NUnit. You can define multiple tests inside a single test component, as long as they are based on the special bUnit test components, currently either <xref:Bunit.Fixture> or <xref:Bunit.SnapshotTest>. 
 
 Besides that, Blazor test components has to inherit from  <xref:Bunit.TestComponentBase>, e.g.:
 
@@ -35,7 +35,7 @@ The following two sections will show how to create tests using bUnit's <xref:Bun
 
 ### Creating a Test using the `<Fixture>` Component
 
-Lets see a simple example, where we test the following `<HelloWorld>` component using the bUnit <xref:Bunit.Fixture> component:
+Let's see a simple example, where we test the following `<HelloWorld>` component using the bUnit <xref:Bunit.Fixture> component:
 
 [!code-html[HelloWorld.razor](../../samples/components/HelloWorld.razor)]
 
@@ -51,7 +51,7 @@ Let's break down what is going on in this test:
 - The <xref:Bunit.Fixture> component's `Test` parameter takes a method, which is called when the test runs, and is passed the <xref:Bunit.Fixture> component.
 - In the test method, we:
   - Use the <xref:Bunit.Fixture.GetComponentUnderTest``1> to get the `HelloWorld` declared in the <xref:Bunit.Fixture>.
-  - Verify the rendered markup from the `HelloWorld` component using the <xref:Bunit.MarkupMatchesAssertExtensions.MarkupMatches(Bunit.IRenderedFragment,System.String,System.String)> method, which performs a semantic comparison of the expected markup with the rendered markup.
+  - Verify the rendered markup from the `HelloWorld` component using the <xref:Bunit.MarkupMatchesAssertExtensions.MarkupMatches> method, which performs a semantic comparison of the expected markup with the rendered markup.
 
 > [!TIP]
 > Learn more about how the semantic HTML/markup comparison in bUnit work, and how to customize it on the <xref:semantic-html-comparison> page.
@@ -63,7 +63,7 @@ Let's break down what is going on in this test:
 
 In snapshot testing, you declare your input (e.g. one or more component under test) and the expected output, and the library will automatically tell you if they do not match. With bUnit, this comparison is done using a smart built-in semantic HTML comparison logic.
 
-Lets see a simple example, where we test the following `<HelloWorld>` component using the bUnit <xref:Bunit.SnapshotTest> component:
+Let's see a simple example, where we test the following `<HelloWorld>` component using the bUnit <xref:Bunit.SnapshotTest> component:
 
 [!code-html[HelloWorld.razor](../../samples/components/HelloWorld.razor)]
 
@@ -84,7 +84,7 @@ When the test runs, the <xref:Bunit.SnapshotTest> component will automatically c
 
 ### Passing Parameters to Components Under Test
 
-Since we are declaring our component under test in Razor syntax, passing parameters to the component under test is exactly the same as passing parameters in normal Blazor components. This is the same for tests created with both the <xref:Bunit.Fixture> and <xref:Bunit.SnapshotTest> components.
+Since we are declaring our component under test in Razor syntax, passing parameters to the component under test is the same as passing parameters in normal Blazor components. This is the same for tests created with both the <xref:Bunit.Fixture> and <xref:Bunit.SnapshotTest> components.
 
 In this example, we are passing both attribute parameters and child content to the component under test, in this case, a basic `<Alert>` component:
 
@@ -94,7 +94,7 @@ Injecting services into the components under test is covered on the <xref:inject
 
 ## Further Reading
 
-Now that we've covered the basics of writing tests using Razor syntax, you can continue digging deeper, e.g. by looking at:
+Now that we have covered the basics of writing tests using Razor syntax, you can continue digging deeper, e.g. by looking at:
 
 - <xref:fixture-options>
 - <xref:snapshot-options>