Spelling and gramma changes from Packt editor

README.md

@@ -15,7 +15,7 @@
 - Pass parameters, cascading values and inject services into components under test
 - Mock `IJSRuntime`, Blazor authentication and authorization, and others
 
-bUnit builds on top of existing unit testing frameworks such as xUnit, NUnit, and MSTest, which run the Blazor components tests in just the same way as any normal unit test. bUnit runs a test in milliseconds, compared to browser-based UI tests which usually take seconds to run. 
+bUnit builds on top of existing unit testing frameworks such as xUnit, NUnit, and MSTest, which run the Blazor component tests in just the same way as any normal unit test. bUnit runs a test in milliseconds, compared to browser-based UI tests which usually take seconds to run. 
 
 **Go to [bUnit.egilhansen.com](https://bunit.egilhansen.com) to learn more.**
 

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

@@ -12,26 +12,26 @@ Use **bUnit** to render the component under test, pass in its parameters, inject
 Rendering a component happens through bUnit's <xref:Bunit.TestContext>. The result of the rendering is an `IRenderedComponent`, referred to as a "rendered component", that provides access to the component instance and the markup produced by the component.
 
 > [!NOTE]
-> The preview and beta versions of bUnit included an experimental feature for writing tests using two test components, `<Fixture>` and `<SnapshotTest>`. Since there is now a better way to write tests in `.razor` files, the old experimental feature has been moved into a separate project named `bunit.web.testcomponents`. It is kept around to not break early adopters, but _no additional features or improvements_ is planned to it.
+> The preview and beta versions of bUnit included an experimental feature for writing tests using two test components, `<Fixture>` and `<SnapshotTest>`. Since there is now a better way to write tests in `.razor` files, the old experimental feature has been moved into a separate project named `bunit.web.testcomponents`. It is kept around to not break early adopters, but _no additional features or improvements_ are planned to it.
 > 
 > To learn more, head over to the [bunit.web.testcomponents project](https://github.com/egil/bUnit/tree/main/src/bunit.web.testcomponents) on GitHub.
 
 ## Write tests in `.cs` or `.razor` files
 
 bUnit works with MSTest, NUnit, and xUnit, and it allows you to write the unit tests in either `.cs` or `.razor` files. 
 
-The latter, writing tests in `.razor` files, provides an easier way to declare component- and HTML-markup in the tests, so it will most likely be the go to for many people in the future.
+The latter, writing tests in `.razor` files, provides an easier way to declare component markup and HTML markup in the tests, so it will most likely be the go-to for many people in the future.
 
 *However*, the current Razor editor in Visual Studio 2019 does not offer all the code editing features available in the C# editor, and has some formatting bugs on top of that, so that is something to consider if you choose to write tests in `.razor` files.
 
-The following sections will show how to get started writing tests in either `.cs` or `.razor` files.
+The following sections show how to get started writing tests in either `.cs` or `.razor` files.
 
 ## Creating basic tests in `.razor` files
 
 Before writing tests in `.razor` files, a few things needs to be in place:
 
 1. Make sure the test project has the SDK type set to `Microsoft.NET.Sdk.Razor`. Otherwise the Blazor compiler will not translate your `.razor` files into runnable code.
-2. Add a `_Imports.razor` file to the test project. It serves the same purpose as `_Imports.razor` files in regular Blazor projects. These using statements are useful to add right away:   
+2. Add an `_Imports.razor` file to the test project. It serves the same purpose as `_Imports.razor` files in regular Blazor projects. These using statements are useful to add right away:   
 
 ```cshtml
 @using Microsoft.AspNetCore.Components.Forms
@@ -43,7 +43,7 @@ Before writing tests in `.razor` files, a few things needs to be in place:
 @using Bunit.TestDoubles
 ```
 
-Also add a using statement for your general purpose testing framework, e.g. `@using Xunit` for xUnit.
+Also add an using statement for your general purpose testing framework, e.g. `@using Xunit` for xUnit.
 
 With that in place, lets look at a simple example that tests the following `<HelloWorld>` component:
 
@@ -71,7 +71,7 @@ With that in place, lets look at a simple example that tests the following `<Hel
 
 The test above does the following:
 
-1. Creates a new instance of the disposable bUnit <xref:Bunit.TestContext>, and assigns it to `ctx` variable using the `using var` syntax to avoid unnecessary source code indention.
+1. Creates a new instance of the disposable bUnit <xref:Bunit.TestContext>, and assigns it to `ctx` the variable using the `using var` syntax to avoid unnecessary source code indention.
 2. Renders the `<HelloWorld>` component using <xref:Bunit.TestContext>, which is done through the <xref:Bunit.TestContext.Render(Microsoft.AspNetCore.Components.RenderFragment)> method. We cover passing parameters to components on the <xref:passing-parameters-to-components> page.
 3. Verifies the rendered markup from the `<HelloWorld>` component using the `MarkupMatches` method. The `MarkupMatches` method performs a semantic comparison of the expected markup with the rendered markup.
 
@@ -83,7 +83,7 @@ The test above does the following:
 
 ### Secret sauce of '.razor' files tests
 
-The trick employed in these tests is the "[inline Razor templates syntax](https://docs.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-5.0#razor-templates)", i.e. where a render fragment is simply created using the `@<{HTML tag}>...</{HTML tag}>` notation. In that notation there is no need to do any escaping of e.g. the quatation mark (`"`), that is usually associated with working with markup in C# code.
+The trick employed in these tests is the "[inline Razor templates syntax](https://docs.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-5.0#razor-templates)", i.e. where a render fragment is simply created using the `@<{HTML tag}>...</{HTML tag}>` notation. In that notation there is no need to do any escaping of e.g. the quotation mark (`"`), that is usually associated with working with markup in C# code.
 
 One small caveat to be aware of is that the inline Razor templates syntax only supports one outer element, e.g. this is OK:
 
@@ -102,7 +102,7 @@ However, this will **not** work:
  <Bar></Bar>
 ```
 
-There is a simple workaround though. Wrap all elements in the special Blazor element `<text>`. The `<text>` element will not be part of the rendered output, but is provides a simple way to group multiple root elements into a single inline Razor templates. E.g.:
+There is a simple workaround though: wrap all elements in the special Blazor element `<text>`. The `<text>` element will not be part of the rendered output, but it provides a simple way to group multiple root elements into a single inline Razor template. E.g.:
 
 ```cshtml
 @<text>
@@ -113,7 +113,7 @@ There is a simple workaround though. Wrap all elements in the special Blazor ele
 
 ### Remove boilerplate code from tests
 
-We can remove some boilerplate code from each test by making the <xref:Bunit.TestContext> implicitly available to the test class, so we don't have to have `using var ctx = new Bunit.TestContext();` in every test. This can be done like this:
+We can remove some boilerplate code from each test by making the <xref:Bunit.TestContext> implicitly available to the test class, so we don't have to have `using var ctx = new Bunit.TestContext();` in every test. This can be done like so:
 
 # [xUnit](#tab/xunit)
 
@@ -146,7 +146,7 @@ Then methods like <xref:Bunit.TestContext.Render(Microsoft.AspNetCore.Components
 > [!IMPORTANT]
 > All the examples in the documentation explicitly new up a `TestContext`, i.e. `using var ctx = new TestContext()`. If you are using the trick above and have your test class inherit from `TestContext`, you should **NOT** new up a `TestContext` in test methods also. 
 > 
-> Simply call the test contest's methods directly, as they are available in your test class. 
+> Simply call the test context's methods directly, as they are available in your test class. 
 > 
 > For example, `var cut = ctx.Render(@<HelloWorld/>);`  
 > becomes `var cut = Render(@<HelloWorld/>);`.
@@ -180,7 +180,7 @@ This is a simple example of writing tests in `.cs` files which tests the followi
 
 The test above does the following:
 
-1. Creates a new instance of the disposable bUnit <xref:Bunit.TestContext>, and assigns it to `ctx` variable using the `using var` syntax to avoid unnecessary source code indention.
+1. Creates a new instance of the disposable bUnit <xref:Bunit.TestContext>, and assigns it to the `ctx` variable using the `using var` syntax to avoid unnecessary source code indention.
 2. Renders the `<HelloWorld>` component using <xref:Bunit.TestContext>, which is done through the <xref:Bunit.TestContext.RenderComponent``1(System.Action{Bunit.ComponentParameterCollectionBuilder{``0}})> method. We cover passing parameters to components on the <xref:passing-parameters-to-components> page.
 3. Verifies the rendered markup from the `<HelloWorld>` component using the `MarkupMatches` method. The `MarkupMatches` method performs a semantic comparison of the expected markup with the rendered markup.
 
@@ -192,7 +192,7 @@ The test above does the following:
 
 ### Remove boilerplate code from tests
 
-We can remove some boilerplate code from each test by making the <xref:Bunit.TestContext> implicitly available to the test class, so we don't have to have `using var ctx = new Bunit.TestContext();` in every test. This can be done like this:
+We can remove some boilerplate code from each test by making the <xref:Bunit.TestContext> implicitly available to the test class, so we don't have to have `using var ctx = new Bunit.TestContext();` in every test. This can be done like so:
 
 # [xUnit](#tab/xunit)
 
@@ -206,7 +206,7 @@ Since xUnit instantiates test classes for each execution of the test methods ins
 
 [!code-csharp[BunitTestContext.cs](../../../samples/tests/nunit/BunitTestContext.cs)]
 
-Since NUnit instantiates a test class only once for all tests inside it, we cannot simply inherit directly from <xref:Bunit.TestContext> as we want a fresh instance of <xref:Bunit.TestContext> for each test. Instead, we create a helper class, `BunitTestContext`, listed above, and use that to hook into NUnit's `[SetUp]` and `[TearDown]` methods, which runs before and after each test.
+Since NUnit instantiates a test class only once for all tests inside it, we cannot simply inherit directly from <xref:Bunit.TestContext> as we want a fresh instance of <xref:Bunit.TestContext> for each test. Instead, we create a helper class, `BunitTestContext`, listed above, and use that to hook into NUnit's `[SetUp]` and `[TearDown]` methods, which run before and after each test.
 
 Then methods like <xref:Bunit.TestContext.RenderComponent``1(System.Action{Bunit.ComponentParameterCollectionBuilder{``0}})> can be called directly from each test, as seen in the listing above.
 
@@ -223,7 +223,7 @@ Then methods like <xref:Bunit.TestContext.RenderComponent``1(System.Action{Bunit
 ***
 
 > [!IMPORTANT]
-> All the examples in the documentation explicitly new up a `TestContext`, i.e. `using var ctx = new TestContext()`. If you are using the trick above and have your test class inherit from `TestContext`, you should **NOT** new up a `TestContext` in test methods also. 
+> All the examples in the documentation explicitly new up a `TestContext`, i.e. `using var ctx = new TestContext()`. If you are using the trick above and have your test class inherit from `TestContext`, you should **NOT** new up another `TestContext` in test methods also. 
 > 
 > Simply call the test contest's methods directly, as they are available in your test class. 
 > 
@@ -232,7 +232,7 @@ Then methods like <xref:Bunit.TestContext.RenderComponent``1(System.Action{Bunit
 
 ## Further reading
 
-With the basics out of the way, next we will look at how to pass parameters and inject services into our component under test. After that, we will cover ways we can verify the outcome of a rendering in more detail
+With the basics out of the way, next we will look at how to pass parameters and inject services into our component under test. After that, we will cover the ways in which we can verify the outcome of a rendering in more detail
 
 - <xref:passing-parameters-to-components>
 - <xref:inject-services>

docs/site/docs/interaction/trigger-renders.md

@@ -9,7 +9,7 @@ To trigger a re-render of a component under test, a reference to it through a <x
 
 In `.razor` based tests, using the <xref:Bunit.TestContext>'s <xref:Bunit.TestContext.Render``1(Microsoft.AspNetCore.Components.RenderFragment)> method also returns an <xref:Bunit.IRenderedComponent`1> (as opposed to the <xref:Bunit.TestContext.Render(Microsoft.AspNetCore.Components.RenderFragment)> method which returns the more simple <xref:Bunit.IRenderedFragment>). 
 
-If you have a <xref:Bunit.IRenderedFragment> or a <xref:Bunit.IRenderedComponent`1> in a test, but need a child component's <xref:Bunit.IRenderedComponent`1>, then use the `FindComponent<TComponent>()` or the `FindComponents<TComponent>()` methods, which traverses down the render tree and finds rendered components.
+If you have a <xref:Bunit.IRenderedFragment> or a <xref:Bunit.IRenderedComponent`1> in a test, but need a child component's <xref:Bunit.IRenderedComponent`1>, then use the `FindComponent<TComponent>()` or the `FindComponents<TComponent>()` methods, which traverse down the render tree and finds rendered components.
 
 With a <xref:Bunit.IRenderedComponent`1>, it is possible to cause the component to render again directly through the [`Render()`](xref:Bunit.RenderedComponentRenderExtensions.Render``1(Bunit.IRenderedComponentBase{``0})) method or one of the [`SetParametersAndRender()`](xref:Bunit.RenderedComponentRenderExtensions.SetParametersAndRender``1(Bunit.IRenderedComponentBase{``0},System.Action{Bunit.ComponentParameterCollectionBuilder{``0}})) methods, or indirectly through the [`InvokeAsync()`](xref:Bunit.IRenderedFragmentBase.Bunit.RenderedFragmentInvokeAsyncExtensions.InvokeAsync(System.Action)) method.
 

docs/site/docs/misc-test-tips.md

@@ -41,7 +41,7 @@ This makes the tooling in Visual Studio and other IDEs automatically assign the
 
 ## Capturing logs from ILogger in test output
 
-It can sometimes be helpful to capture log messages sent to `ILogger`'s in the components under test and/or the bUnit and Blazor internals. 
+It can sometimes be helpful to capture log messages sent to `ILogger` types in the components under test and/or the bUnit and Blazor internals. 
 
 With xUnit, this can be done as follows:
 

docs/site/docs/providing-input/inject-services-into-components.md

@@ -14,7 +14,7 @@ In bUnit, you register the services in the `Services` collection _before_ you re
 > [!NOTE]
 > The `AddSingleton()` method is only available on the `Services` collection if you **import the `Microsoft.Extensions.DependencyInjection` namespace in your test class**.
 
-The following sections demonstrate how to do. The examples we will cover will test the `<WeatherForecasts>` component listed below, which depends on the `IWeatherForecastService` service, injected in line 1:
+The following sections demonstrate how to do this. The examples we will cover will test the `<WeatherForecasts>` component listed below, which depends on the `IWeatherForecastService` service, injected in line 1:
 
 [!code-cshtml[WeatherForecasts.razor](../../../samples/components/WeatherForecasts.razor?highlight=1)]
 
@@ -49,7 +49,7 @@ Here is a test where the fallback service provider is used:
 
 [!code-csharp[](../../../samples/tests/xunit/FallBackServiceProviderUsage.cs?start=11&end=16)]
 
-In this example, the `DummyService` is provided by the fallback service provider, since it is not register in the default service provider.
+In this example, the `DummyService` is provided by the fallback service provider, since it is not registered in the default service provider.
 
 ## Further reading
 

docs/site/index.md

@@ -38,7 +38,7 @@ This test uses bUnit's test context to render the `Counter` component with the `
 
 ### NuGet downloads
 
-bUnit is available on NuGet in various incarnations. Most should just pick the [bUnit](https://www.nuget.org/packages/bunit/) package:
+bUnit is available on NuGet in various incarnations. Most users should just pick the [bUnit](https://www.nuget.org/packages/bunit/) package:
 
 | Name | Description | NuGet Download Link |
 | ----- | ----- | ---- |