Initial rewrite of docs. Basic intro is done.

Author: egil

docs/.editorconfig

@@ -0,0 +1,45 @@
+root = true
+
+[*]
+indent_style = space
+tab_size = 2
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = false
+
+[*.cs]
+indent_style = space
+tab_size = 2
+trim_trailing_whitespace = true
+insert_final_newline = false
+
+[*.{xml,config,*proj,nuspec,props,resx,targets,yml,tasks}]
+tab_size = 2
+
+[*.{htm,html,css,scss}]
+tab_size = 2
+
+[*.json]
+tab_size = 2
+
+[*.{ps1,psm1}]
+tab_size = 4
+
+[*.sh]
+tab_size = 4
+end_of_line = lf
+
+[*.{yml,yaml,md}]
+indent_style = space
+tab_size = 2
+
+[*.md]
+trim_trailing_whitespace = false
+
+[*.{cs,razor}]
+dotnet_diagnostic.BL0001.severity = none
+dotnet_diagnostic.BL0002.severity = none
+dotnet_diagnostic.BL0003.severity = none
+dotnet_diagnostic.BL0004.severity = none
+dotnet_diagnostic.BL0005.severity = none
+dotnet_diagnostic.BL0006.severity = none

docs/docfx.json

@@ -70,7 +70,8 @@
       "_description": "bUnit is a unit testing library for Blazor Components. You can easily define components under test in C# or Razor syntax and verify outcome using semantic HTML diffing/comparison logic. You can interact with and inspect components, trigger event handlers, provide cascading values, inject services, mock IJsRuntime, and perform snapshot testing.",
       "_enableSearch": true,
       "_appLogoPath": "/images/blazor-logo.png",
-      "_disableBreadcrumb": true
+      "_disableBreadcrumb": true,
+      "_disableFooter": true
     },
     "postProcessors": [],
     "markdownEngineName": "markdig",

docs/docs.sln

@@ -0,0 +1,25 @@
+
+Microsoft Visual Studio Solution File, Format Version 12.00
+# Visual Studio Version 16
+VisualStudioVersion = 16.0.30114.105
+MinimumVisualStudioVersion = 10.0.40219.1
+Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "docs", "docs.csproj", "{B6EC06B4-D7EA-46C0-BF20-DFC59A213250}"
+EndProject
+Global
+	GlobalSection(SolutionConfigurationPlatforms) = preSolution
+		Debug|Any CPU = Debug|Any CPU
+		Release|Any CPU = Release|Any CPU
+	EndGlobalSection
+	GlobalSection(ProjectConfigurationPlatforms) = postSolution
+		{B6EC06B4-D7EA-46C0-BF20-DFC59A213250}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+		{B6EC06B4-D7EA-46C0-BF20-DFC59A213250}.Debug|Any CPU.Build.0 = Debug|Any CPU
+		{B6EC06B4-D7EA-46C0-BF20-DFC59A213250}.Release|Any CPU.ActiveCfg = Release|Any CPU
+		{B6EC06B4-D7EA-46C0-BF20-DFC59A213250}.Release|Any CPU.Build.0 = Release|Any CPU
+	EndGlobalSection
+	GlobalSection(SolutionProperties) = preSolution
+		HideSolutionNode = FALSE
+	EndGlobalSection
+	GlobalSection(ExtensibilityGlobals) = postSolution
+		SolutionGuid = {94A09891-FA4C-48F3-85AF-D6E7728A03FC}
+	EndGlobalSection
+EndGlobal

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

@@ -225,5 +225,6 @@ dotnet add <NAME OF COMPONENT PROJECT>.csproj reference <NAME OF TEST PROJECT>.c
 
 ## Further reading
 
-- <xref:writing-first-csharp-test>
-- <xref:misc-test-tips>
+Now you are ready to write some times. 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

@@ -0,0 +1,8 @@
+---
+uid: fixture-options
+title: Fixture test options
+---
+
+# `<Fixture>` options
+
+TODO!

docs/docs/getting-started/getting-started.md

@@ -7,26 +7,11 @@ title: 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.
 
-The sections below takes you through each of the steps you need to get started:
-
-## Creating a test project
-
-First you need a test project to store your component tests inside. This is covered on the <xref:create-test-project> page.
-
-## The basics of testing Blazor components
-
-To test a component, you first have to render it with parameters, cascading values, and services passed into it. Then, you need access to the component's instance and the markup it has produced, so you can inspect and interact with both.
-
-There are three different ways of doing this in bUnit:
-
-1. [**C# based tests**](/docs/csharp-based-testing.html)  
+1. **<xref:create-test-project>** covers setting up a bUnit test project.
+2. **<xref:writing-csharp-tests>** covers the basics of writing tests in C#.  
    With C# based tests, you write all your testing logic in C# files, i.e. like regular unit tests.
-2. [**Razor based tests**](/docs/razor-based-testing.html)  
+3. **<xref:writing-razor-tests>** covers the basics of writing tests in Razor and C# syntax.  
    With Razor based tests, you write tests in `.razor` files, which allows you to declare, in Razor syntax, the component under test and other markup fragments you need. You still write your assertions via C# in the .razor file, inside `@code {...}` blocks.
-3. [**Snapshot tests**](/docs/snapshot-testing.html)  
-   Snapshot tests are written in `.razor` files. A test contains a definition of an input markup/component and the expected output markup. The library will then automatically perform an semantic HTML comparison. Very little C# is needed in this, usually only to configure services.
-
-To learn more, read the [Basics of Blazor component testing](/docs/basics-of-blazor-component-testing.html) page.
 
 ## Examples
 

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

@@ -0,0 +1,8 @@
+---
+uid: snapshot-options
+title: SnapshotTest options
+---
+
+# `<SnapshotTest>` options
+
+TODO!

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

@@ -0,0 +1,93 @@
+---
+uid: writing-csharp-tests
+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*.
+
+**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:
+
+[!code-cshtml[HelloWorld.razor](../../samples/components/HelloWorld.razor)]
+
+# [xUnit](#tab/xunit)
+
+[!code-csharp[HelloWorldTest.cs](../../samples/tests/xunit/HelloWorldTest.cs)]
+
+# [NUnit](#tab/nunit)
+
+[!code-csharp[HelloWorldTest.cs](../../samples/tests/nunit/HelloWorldTest.cs)]
+
+> [!NOTE]
+> `TestContext` is an ambiguous reference between `TestContext` and `NUnit.Framework.TestContext`, so you have to specify the `Bunit` namespace when referencing `TestContext` to resolve the ambiguity for the compiler. Alternatively, you can give bUnit's `TestContext` a different name during import, e.g.: `using BunitTestContext = Bunit.TestContext;` 
+
+# [MSTest](#tab/mstest)
+
+[!code-csharp[HelloWorldTest.cs](../../samples/tests/mstest/HelloWorldTest.cs)]
+
+> [!NOTE]
+> `TestContext` is an ambiguous reference between `TestContext` and `Microsoft.VisualStudio.TestTools.UnitTesting.TestContext`, so you have to specify the `Bunit` namespace when referencing `TestContext` to resolve the ambiguity for the compiler. Alternatively, you can give bUnit's `TestContext` a different name during import, e.g.:   
+> `using BunitTestContext = Bunit.TestContext;` 
+
+***
+
+In this test, we do the following:
+
+1. New up the disposable <xref:Bunit.TestContext>, and assign it using the `using var` syntax, to avoid unnecessary indention.
+2. Render the `<HelloWorld>` component using <xref:Bunit.TestContext>, which we do through the <xref:Bunit.TestContext.RenderComponent``1(Bunit.Rendering.ComponentParameter[])> method. We will cover passing parameters to components elsewhere.
+3. 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.
+
+> [!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.
+
+> [!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
+
+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:
+
+# [xUnit](#tab/xunit)
+
+[!code-csharp[HelloWorldImplicitContextTest.cs](../../samples/tests/xunit/HelloWorldImplicitContextTest.cs)]
+
+Since xUnit instantiates test classes for each execution of test methods inside them and disposes them after each test method has run, we simply inherit from <xref:Bunit.TestContext>, and methods like <xref:Bunit.TestContext.RenderComponent``1(Bunit.Rendering.ComponentParameter[])> can now be called directly from each test, as seen in the listing above. 
+
+# [NUnit](#tab/nunit)
+
+[!code-csharp[HelloWorldImplicitContextTest.cs](../../samples/tests/nunit/HelloWorldImplicitContextTest.cs)]
+
+[!code-csharp[BunitTestContext.cs](../../samples/tests/nunit/BunitTestContext.cs)]
+
+Since NUnit instantiates the test class is once, 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`, which is listed above, and use that to hook into NUnit's `[SetUp]` and `[TearDown]` methods, which runs before and after each test.
+
+Then methods like <xref:Bunit.TestContext.RenderComponent``1(Bunit.Rendering.ComponentParameter[])> can now be called directly from each test, as seen in the listing above.
+
+# [MSTest](#tab/mstest)
+
+[!code-csharp[HelloWorldImplicitContextTest.cs](../../samples/tests/mstest/HelloWorldImplicitContextTest.cs)]
+
+[!code-csharp[BunitTestContext.cs](../../samples/tests/mstest/BunitTestContext.cs)]
+
+Since MSTest instantiates the test class is once, 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`, which is listed above, and use that to hook into MSTest's `[TestInitialize]` and `[TestCleanup]` methods, which runs before and after each test.
+
+Then methods like <xref:Bunit.TestContext.RenderComponent``1(Bunit.Rendering.ComponentParameter[])> can now be called directly from each test, as seen in the listing above.
+
+***
+
+## 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.
+
+- <xref:passing-parameters-to-components>
+- <xref:inject-services-into-components>
+- <xref:verify-markup>
+- <xref:verify-component-state>
+- <xref:trigger-event-handlers>