|
| 1 | +# Blazor Component Testing |
| 2 | + |
| 3 | +This framework's goal is to make it easy to write _comprehensive, stable unit tests_ for Blazor Components/Razor Components. |
| 4 | + |
| 5 | +1. [Introduction](#introduction) |
| 6 | +2. [Getting started](#getting-started) |
| 7 | +3. [Examples](#examples) |
| 8 | +4. [References](#references) |
| 9 | +5. [Contribute](#contribute) |
| 10 | + |
| 11 | +## Introduction |
| 12 | + |
| 13 | +**To make tests easy to write**, the framework provides a few different ways of define the **component under test** (CUT): |
| 14 | + |
| 15 | +1. Render components from C# code via the `RenderComponent<TComponent>(params...)` method, that allow you to easily pass component parameters, cascading values, event callbacks to the component. |
| 16 | + |
| 17 | +2. Define components and other markup in Razor syntax using the `<Fixture>` component, and execute the _act_ and _assert_ steps inside `@code { }` blocks in the Razor file (experimental). |
| 18 | + |
| 19 | +3. Create _snapshot tests_ in Razor syntax that automatically compare the rendered input to the expected output (experimental). |
| 20 | + |
| 21 | +**To make it easier to create stable tests**, the library comes with growing set of assertion helpers and strategies. You can: |
| 22 | + |
| 23 | +1. Inspect components state/properties directly. |
| 24 | +2. Query the rendered HTML and assert against that directly. This is supported by [AngleSharp](https://anglesharp.github.io/)'s full implementation of the HTML5 DOM API. |
| 25 | +3. Perform a stable semantic comparison the rendered HTML from a component under test with expected HTML. This is supported by the [AngleSharp.Diffing](https://github.com/AngleSharp/AngleSharp.Diffing) library, which e.g. will ignore insignificant whitespace, attribute order on elements, order of classes in `class="..."` attributes, handle boolean attributes correctly, among other things. |
| 26 | + |
| 27 | +## Getting started |
| 28 | + |
| 29 | +Follow these steps to set up a new test project: |
| 30 | + |
| 31 | +1. Create a new Razor Class Library (`dotnet new razorclasslib`). |
| 32 | +2. Add the following package references to your testing library: |
| 33 | + |
| 34 | + - `Razor.Components.Testing.Library` |
| 35 | + - `Microsoft.NET.Test.Sdk` |
| 36 | + - `xunit.core` |
| 37 | + - `xunit.assert` |
| 38 | + - `xunit.runner.visualstudio` (if using Visual Studio) |
| 39 | + |
| 40 | + Optionally, but recommended packages are [`Moq`](https://github.com/Moq) and [`Shouldly`](https://github.com/shouldly). _Moq_ is a good generic mocking library, and _Shouldly_ is a fluent syntax assert library, that makes test more readable and produce easily readable assert errors. |
| 41 | + |
| 42 | +3. Add a reference to the Blazor (class library) project(s) where the components you want to test is located. |
| 43 | + |
| 44 | +4. Start writing tests (see examples below to get started). |
| 45 | + |
| 46 | +## Examples |
| 47 | + |
| 48 | +Examples are split into three sections, one for each style/declaration type. |
| 49 | + |
| 50 | +1. [C#-based tests](csharp-examples.md) |
| 51 | +2. [Razor/C# mixed-mode tests](razor-examples.md) |
| 52 | +3. [Snapshot tests](snapshot-examples.md) |
| 53 | + |
| 54 | +## References |
| 55 | + |
| 56 | +## Contribute |
| 57 | + |
| 58 | +To get in touch, ask questions or provide feedback, you can: |
| 59 | + |
| 60 | +- Create a new [issue](https://github.com/egil/razor-components-testing-library/issues) |
| 61 | +- Join the library's Gitter channel ([](https://gitter.im/razor-components-testing-library/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)) |
| 62 | +- Ping me on Twitter ([@egilhansen](https://twitter.com/egilhansen)) |
| 63 | + |
| 64 | +There are a few ways you can help improve this library. |
| 65 | + |
| 66 | +1. Tell me if a certain type of component/scenario is hard to test. Create an issue with a minimal example of the component and the kind of assertions you would like to perform. |
| 67 | + |
| 68 | +2. Suggest tweaks to the library's API or assertion helpers (create issue). |
| 69 | + |
| 70 | +3. Find a bug or mistake in the library, create an issue, or even better, send in a pull request. |
| 71 | + |
| 72 | +4. Help with documentation and/or good examples. If you figured out a elegant way to test a scenario, share it through an issue, or add it to the samples project (pull request), or add it to the documentation (pull request). |
0 commit comments