Docs update

Author: egil

docs/docs/tutorials-and-presentations.md docs/docs/external-resources.mddocs/docs/tutorials-and-presentations.md renamed to docs/docs/external-resources.md

@@ -1,3 +1,8 @@
+---
+uid: external-resources
+title: External Resources
+---
+
 # Presentations, guides, articles, tutorials, and blog posts
 Here is a list of some of the content out on the web that covers bUnit. If you produce something you think can be useful to bUnit's users, feel free to add the content to this page and send a pull request.
 

docs/docs/getting-started.md

@@ -1,15 +1,15 @@
 ---
 uid: create-test-project
-title: Creating a new bUnit test project
+title: Creating a new bUnit Test Project
 ---
 
-# 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. 
 
 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
+## Create a Test Project Manually
 
 To create a project for testing you Blazor components that uses either of three general purpose test frameworks, you need to go through these steps:
 
@@ -183,7 +183,7 @@ The end result should be a test project with a `.csproj` that looks like this (o
 
 ***
 
-## Create a test project with bUnit template
+## 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.
 
@@ -223,7 +223,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
 ```
 
-## Further reading
+## 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.
 

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

@@ -1,8 +1,43 @@
----
+---
 uid: fixture-options
-title: Fixture test options
+title: Fixture options in Razor Tests
 ---
 
-# `<Fixture>` options
+# `<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.
+
+
+## Parameters
+
+All the parameters the `<Fixture>` support are shown in the listen 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:
+
+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.
+  
+**Other parameters**
+
+The other parameters affect how the test runs, and how it is displayed in e.g. Visual Studio's Test Explorer:
+
+1. **<xref:Bunit.RazorTesting.RazorTestBase.Description>:**   
+   If a description is provided, it will be displayed by the test runner when the test runs, and in Visual Studio's Test Explorer. If no description is provided, the name of the provided test method is used.
+2. **<xref:Bunit.RazorTesting.RazorTestBase.Skip>:**  
+   If the skip parameter is provided, the test is skipped and the text entered in the skip parameter is passed to the test runner as the reason to skip the test.
+3. **<xref:Bunit.RazorTesting.RazorTestBase.Timeout>:**  
+   If provided, the test runner will terminate the test after the specified amount of time.
+
+## `<ComponentUnderTest>` and `<Fragment>`
+
+## Getting `<ComponentUnderTest>` and `<Fragment>`
 
-TODO!
+## Example

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

@@ -1,9 +1,9 @@
 ---
 uid: getting-started
-title: Getting started with bUnit
+title: Getting Started with bUnit
 ---
 
-# Getting started with bUnit
+# Getting Started with bUnit
 
 To get started writing tests for your Blazor components, you first need to set up a test project. Then you can start writing your tests, using either C# or Razor syntax. 
 

docs/docs/getting-started/index.md

@@ -1,8 +1,8 @@
----
+---
 uid: snapshot-options
-title: SnapshotTest options
+title: SnapshotTest Options in Razor Tests
 ---
 
-# `<SnapshotTest>` options
+# `<SnapshotTest>` Options in Razor Tests
 
 TODO!

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

@@ -1,17 +1,17 @@
 ---
 uid: writing-csharp-tests
-title: Writing tests in C# for Blazor components
+title: Writing Tests in C# for Blazor Components
 ---
 
-# 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*.
 
 **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
+## Creating a Basic Test
 
 Lets see a simple example, where we test the following `<HelloWorld>` component:
 
@@ -50,7 +50,7 @@ In this test, we do the following:
 > [!TIP]
 > In bUnit tests, we like to use the abbreviation `CUT`, short for "component under test", to indicate the component that is being tested. This is inspired by the common testing abbreviation `SUT`, short for "system under test".
 
-## Remove boilerplate code from tests
+## 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 do not have to have `using var ctx = new Bunit.TestContext();` in every test. This can be done like this:
 
@@ -82,7 +82,7 @@ Then methods like <xref:Bunit.TestContext.RenderComponent``1(Bunit.Rendering.Com
 
 ***
 
-## Further reading
+## Further Reading
 
 With the basics out of the way, we will next look at how to pass parameters and inject services into our components under test, and after that, cover in more details the various ways we can verify the outcome of a rendering.
 

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

@@ -1,29 +1,29 @@
 ---
 uid: writing-razor-tests
-title: Writing tests in Razor syntax for Blazor components
+title: Writing Tests in Razor Syntax for Blazor Components
 ---
 
-# Writing tests in Razor syntax for Blazor components
+# 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.
 
-> [!TIP]
+> [!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. 
 > 
 > However, they will _not_ show up before the Blazor test component has been compiled into C# by the Blazor compiler, and if there are compile-errors from the Blazor compiler, they might appear to come and go in the Test Explorer.
 
-## Create a test specific `_Imports.razor` file
+## 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:
 
 [!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
+## 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>. 
 
@@ -33,7 +33,7 @@ Besides that, Blazor test components has to inherit from  <xref:Bunit.TestCompon
 
 The following two sections will show how to create tests using bUnit's <xref:Bunit.Fixture> and <xref:Bunit.SnapshotTest> components.
 
-### Creating a test using the `<Fixture>` component
+### 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:
 
@@ -59,7 +59,7 @@ Let's break down what is going on in this test:
 > [!TIP]
 > In bUnit tests, we like to use the abbreviation `CUT`, short for "component under test", to indicate the component that is being tested. This is inspired by the common testing abbreviation `SUT`, short for "system under test".
 
-### Creating a test using the `<SnapshotTest>` component
+### Creating a Test using the `<SnapshotTest>` Component
 
 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.
 
@@ -82,7 +82,7 @@ When the test runs, the <xref:Bunit.SnapshotTest> component will automatically c
 > [!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.
 
-### Passing parameters to components under test
+### 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.
 
@@ -92,7 +92,7 @@ In this example, we are passing both attribute parameters and child content to t
 
 Injecting services into the components under test is covered on the <xref:inject-services-into-components> page.
 
-## Further reading
+## 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:
 

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

@@ -1,13 +1,13 @@
 ---
 uid: misc-test-tips
-title: Miscellaneous bUnit testing tips
+title: Miscellaneous bUnit Testing Tips
 ---
 
-# Miscellaneous bUnit testing tips
+# Miscellaneous bUnit Testing Tips
 
 Here is a few testing tips and tricks that have proven useful to us.
 
-## Projects structure and tips and tricks
+## Projects Structure and Tips and Tricks
 
 The recommended solution/project structure for a test and production code project set-up is:
 
@@ -27,7 +27,7 @@ test
   | SubComponent1Test.cs
 ```
 
-## Use same root namespace and folder structure in both test- and production project
+## Use same Root Namespace and Folder Structure
 
 A neat trick, which will limit the `import` statements needed in your test project, is to set the root namespace to the same as that of the production code project, _AND_ use the same folder structure as shown above. Following the example above, the `MyComponentLibTests.csproj` file should contain:
 
@@ -37,7 +37,7 @@ A neat trick, which will limit the `import` statements needed in your test proje
 </PropertyGroup>
 ```
 
-## Capture logs from ILogger in test output
+## Capture Logs from ILogger in Test Output
 
 TODO: Document XunitLogger and XunitLoggerFactory
 

docs/docs/misc-test-tips.md

@@ -1,9 +1,9 @@
----
+---
 uid: mocking
-title: Mocking component dependencies
+title: Mocking Component Dependencies
 ---
 
-# Mocking component dependencies
+# Mocking Component Dependencies
 
 intro