docs: fixture options and tweaks to toc

Author: egil

.github/workflows/CI-CD-Docs.yml

@@ -45,7 +45,7 @@ jobs:
       - name: Deploy
         uses: JamesIves/github-pages-deploy-action@releases/v3
         with:
-          ACCESS_TOKEN: ${{ secrets.GH_DOCS }}
+          ACCESS_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           BRANCH: gh-pages # The branch the action should deploy to.
           FOLDER: docs/_site # The folder the action should deploy.
           CLEAN: true

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

@@ -27,7 +27,10 @@ Let us start by looking at the parameters that takes a method as input first. Th
 
 In the example above, the setup and test methods are declared in a `@code { }` block nested inside the <xref:Bunit.Fixture> component. This visually groups the methods nicely to the <xref:Bunit.Fixture> component, but it's not a requirement. 
 
-You can have the methods anywhere inside the test component you want, which can be useful, if you for example have a common setup method that multiple Razor tests in the same test component shares. The methods can also be declared in the parameter directly, e.g.: `<Fixture Setup="f => f.Services.AddMockJsRuntime" ...>`.
+You can have the methods anywhere inside the test component you want, which can be useful, if you for example have a common setup method that multiple Razor tests in the same test component shares. The methods can also be declared in the parameter directly, e.g.: `<Fixture Setup="f => f.Services.AddMockJsRuntime()" ...>`.
+
+> [!TIP]
+> Learn more about mocking and `AddMockJsRuntime()` on the <xref:mocking-ijsruntime> page.
 
 **Other parameters**
 
@@ -80,10 +83,26 @@ The generic versions of <xref:Bunit.Fixture.GetComponentUnderTest``1> and <xref:
 
 ## Example
 
-TODO:
+Let's look at a complete example, where we have a simple task list component, `<SimpleTodo>`, listed below, that have a service injected, receive a cascading value, and changes between renders:
+
+[!code-html[SimpleTodo.razor](../../samples/components/SimpleTodo.razor)]
+
+In the test, we want to verify that:
+
+- The `<form>` resets itself correctly after a task has been added
+- That the task was added correctly to the task list
+- That the "Theme" cascading value was correctly assigned to the task list
+
+The test looks like this:
+
+[!code-html[SimpleTodoTest.razor](../../samples/tests/razor/SimpleTodoTest.razor?highlight=4,5,8-10,13,20,29,30,35-37,44)]
+
+Let's look at whats going on in this test:
+
+1. The fixture has both a setup and test method specified. The setup methods is used to register an empty list of tasks, that the `<SimpleTodo>` component requires.
+2. The `<SimpleTodo>` component is wrapped in a `<CascadingValue>` component that passes down the "Theme" cascading value.
+3. The first `<Fragment>` does not have an `Id`, since the `GetFragment()` method will pick the first fragment, if no `id` is provided to it.
+4. The second `<Fragment Id="expected tasks">` does have an `Id` to make it possible to get it, through a call to the `GetFragment("expected tasks")` method.
+5. The test uses the generic version of `GetComponentUnderTest<SimpleTodo>()`, which gives us access to the instance of `SimpleTodo`, and allows us to inspect its properties, e.g. `ThemeClass`.
 
-1. Create a basic component that takes a cascading value, a service, and maybe some child content, and it should have a initial rendered output and something after e.g. a click event.
-2. Add a setup method that registers the service
-3. Add two fragments, one to verify the inital rendered output and one for the output after click.
-4. Show how GetCompnentUnderTest returns not the cascading value
-5. Show how get fragment is used with and without id, and returns fragments without
+We will cover the details of the "act" and "assertion" step in the <xref:interaction> and <xref:verification> pages. Learn more about injecting services into components under test on the <xref:inject-services-into-components> page.

docs/docs/getting-started/index.md

@@ -18,7 +18,7 @@ These three pages will teach you *the basics*:
 After reading those, these topics will take you to the *next level*:
 
 1. **[Providing different types of input](xref:providing-input)** to a component under test, e.g. passing parameters or injecting services.
-2. **[Verifying output in various ways](xref:verifying-output)** from a component under test, e.g. inspecting the rendered markup.
+2. **[Verifying output in various ways](xref:verification)** from a component under test, e.g. inspecting the rendered markup.
 3. **[Mocking dependencies](xref:mocking)** a component under test has, e.g. the `IJsRuntime` or `HttpClient`.
 
 ## Examples

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

@@ -10,7 +10,7 @@ title: Writing Tests in Razor Syntax for Blazor Components
 
 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]
+> [!NOTE]
 > 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.

docs/docs/interaction/index.md

@@ -0,0 +1,6 @@
+---
+uid: interaction
+title: Interacting with a Component Under Test
+---
+
+# Interacting with a Component Under Test

…roviding-input/trigger-event-handlers.md …cs/interaction/trigger-event-handlers.mddocs/docs/providing-input/trigger-event-handlers.md renamed to docs/docs/interaction/trigger-event-handlers.md docs/docs/providing-input/trigger-event-handlers.md renamed to docs/docs/interaction/trigger-event-handlers.md

@@ -8,11 +8,13 @@
 # [Providing Input](xref:providing-input)
 ## [Parameters and Cascading Values](xref:passing-parameters-to-components)
 ## [Inject Services](xref:inject-services-into-components)
+## [Configure 3rd Party Libraries](xref:configure-3rd-party-libs)
+
+# [Interaction](xref:interaction)
 ## [Trigger Event Handlers](xref:trigger-event-handlers)
 ## [Trigger Renders](xref:trigger-renders)
-## [Configure 3rd Party Libraries](xref:configure-3rd-party-libs)
 
-# [Verifying output](xref:verifying-output)
+# [Verifying output](xref:verification)
 ## [Verify Markup](xref:verify-markup)
 ## [Verify Component State](xref:verify-component-state)
 ## [Semantic HTML Markup Comparison](xref:semantic-html-comparison)

…/docs/providing-input/trigger-renders.md docs/docs/interaction/trigger-renders.mddocs/docs/providing-input/trigger-renders.md renamed to docs/docs/interaction/trigger-renders.md docs/docs/providing-input/trigger-renders.md renamed to docs/docs/interaction/trigger-renders.md

@@ -1,5 +1,5 @@
 ---
-uid: verifying-output
+uid: verification
 title: Verifying Output from a Component Under Test
 ---
 

docs/docs/toc.md

@@ -0,0 +1,26 @@
+@inject List<string> Tasks
+
+<form>
+    <input @bind-value=@newTaskValue placeholder="Add todo here . . ." type="text" />
+    <button type="submit" @onclick=@HandleTaskAdded>Add task</button>
+</form>
+<ul id="tasks" class=@ThemeClass>
+    @foreach (var task in Tasks)
+    {
+        <li>@task</li>
+    }
+</ul>
+@code {
+    [CascadingParameter(Name = "Theme")]
+    public string ThemeClass { get; set; } = string.Empty;
+
+    private string newTaskValue = string.Empty;
+
+    private void HandleTaskAdded()
+    {
+        if (!string.IsNullOrWhiteSpace(newTaskValue))
+            Tasks.Add(newTaskValue);
+
+        newTaskValue = string.Empty;
+    }
+}