You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Add FindByLabelText to find elements by the text of their labels (#1252)
* add label, aria-label, wrapped label
* switch to strategy pattern
* feat: support for all element types that can have a label
* feat: support for all element types that can have a wrapped label
* feat: support for all element types that can have an aria-label
* feat: support for all element types that can have an aria-labelledby
* style: remove comment
* fix: use theorydata
* fix: use method instead of list
* failing test to prove the re-rendered element issue
* move to element factory to prevent re-renders causing issues
* fix: switch to array for strategies
* fix: remove todos
* fix: move to new ielementwrapperfactory
* fix: use custom labelnotfoundexception
* feat: support for different casing sensitivity
* chore: add xml docs to indicate defaults of ByLabelTextOptions
* fix: make classes add public
* fix: remove project references
* fix: move to source generator to public
* chore: switch to use wrapper component for tests
* chore: switch to use wrapper component for tests
* chore: rename to labelquerycounter for re-rendering test
* fix: remove warnings
* refactor: remove string duplication in tests
* fix: remove nullability warning
* fix: add sealed to remove warnings
* feat: add support for whitespace
* add xml comments
* fix: labelElement can be null if not found
* chore: fix indention
* chore: remove duplicated word
* fix: make label options immutable
* test: verify generate test output
* chore: remove whitespace in test case name
* refactor: simplify null check
* fix: cover scenario where wrapped label has nested HTML
* fix: rename test
* test: add additional test for nested html with for attributes
* docs: cover FindByLabelText and update verify markup section to discuss different markup verify approaches
* docs: verify-markup.md
Co-authored-by: Steven Giesel <[email protected]>
* refactor: use configure options pattern instead of passing option object
---------
Co-authored-by: Egil Hansen <[email protected]>
Co-authored-by: Steven Giesel <[email protected]>
Copy file name to clipboardExpand all lines: docs/site/docs/verification/verify-markup.md
+58-53Lines changed: 58 additions & 53 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,34 +5,63 @@ title: Verifying markup from a component
5
5
6
6
# Verifying markup from a component
7
7
8
-
When a component is rendered in a test, the result is a <xref:Bunit.IRenderedFragment> or a <xref:Bunit.IRenderedComponent`1>. Through these, it is possible to access the rendered markup (HTML) of the component and, in the case of <xref:Bunit.IRenderedComponent`1>, the instance of the component.
8
+
Generally, the strategy for verifying markup produced by components depends on whether you are creating reusable component library or a single-use Blazor app component.
9
9
10
-
> [!NOTE]
11
-
> An <xref:Bunit.IRenderedComponent`1> inherits from <xref:Bunit.IRenderedFragment>. This page will only cover features of the <xref:Bunit.IRenderedFragment> type. <xref:Bunit.IRenderedComponent`1> is covered on the <xref:verify-component-state> page.
10
+
With a **reusable component library**, the markup produced may be considered part of the externally observable behavior of the component, and that should thus be verified, since users of the component may depend on the markup having a specific structure. Consider using `MarkupMatches` and semantic comparison described below to get the best protection against regressions and good maintainability.
11
+
12
+
When **building components for a Blazor app**, the externally observable behavior of components are how they visibly look and behave from an end-users point of view, e.g. what the user sees and interact with in a browser. In this scenario, consider use `FindByLabelText` and related methods described below to inspect and assert against individual elements look and feel, for a good balance between protection against regressions and maintainability. Learn more about this testing approach at https://testing-library.com.
12
13
13
14
This page covers the following **verification approaches:**
14
15
15
-
- Basic verification of raw markup
16
-
- Semantic comparison of markup
17
16
- Inspecting the individual DOM nodes in the DOM tree
17
+
- Semantic comparison of markup
18
18
- Finding expected differences in markup between renders
19
+
- Verification of raw markup
19
20
20
21
The following sections will cover each of these.
21
22
22
-
## Basic verification of raw markup
23
+
## Result of rendering components
23
24
24
-
To access the rendered markup of a component, just use the <xref:Bunit.IRenderedFragment.Markup> property on<xref:Bunit.IRenderedFragment>. This holds the *raw*HTML from the component as a `string`.
25
+
When a component is rendered in a test, the result is a <xref:Bunit.IRenderedFragment> or a<xref:Bunit.IRenderedComponent`1>. Through these, it is possible to access the rendered markup (HTML) of the component and, in the case of <xref:Bunit.IRenderedComponent`1>, the instance of the component.
25
26
26
-
> [!WARNING]
27
-
> Be aware that all indentions and whitespace in your components (`.razor` files) are included in the raw rendered markup, so it is often wise to normalize the markup string a little. For example, via the string `Trim()` method to make the tests more stable. Otherwise, a change to the formatting in your components might break the tests unnecessarily when it does not need to.
28
-
>
29
-
> To avoid these issues and others related to asserting against raw markup, use the semantic HTML comparer that comes with bUnit, described in the next section.
27
+
> [!NOTE]
28
+
> An <xref:Bunit.IRenderedComponent`1> inherits from <xref:Bunit.IRenderedFragment>. This page will only cover features of the <xref:Bunit.IRenderedFragment> type. <xref:Bunit.IRenderedComponent`1> is covered on the <xref:verify-component-state> page.
The rendered markup from a component is available as a DOM node through the <xref:Bunit.IRenderedFragment.Nodes> property on <xref:Bunit.IRenderedFragment>. The nodes and element types comes from [AngleSharp](https://anglesharp.github.io/) that follows the W3C DOM API specifications and gives you the same results as a state-of-the-art browser’s implementation of the DOM API in JavaScript. Besides the official DOM API, AngleSharp and bUnit add some useful extension methods on top. This makes working with DOM nodes convenient.
33
+
34
+
### Finding DOM elements
35
+
36
+
bUnit supports multiple different ways of searching and querying the rendered HTML elements:
37
+
38
+
-`FindByLabelText(string labelText)` that takes a text string used to label an input element and returns an `IElement` as output, or throws an exception if none are found (this is included in the experimental library [bunit.web.query](https://www.nuget.org/packages/bunit.web.query)). Use this method when possible compared to the generic `Find` and `FindAll` methods.
39
+
-[`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) takes a "CSS selector" as input and returns an `IElement` as output, or throws an exception if none are found.
40
+
-[`FindAll(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.FindAll(Bunit.IRenderedFragment,System.String,System.Boolean)) takes a "CSS selector" as input and returns a list of `IElement` elements.
41
+
42
+
Let's see some examples of using the [`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) and [`FindAll(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.FindAll(Bunit.IRenderedFragment,System.String,System.Boolean)) methods to query the `<FancyTable>` component listed below.
An element found with the [`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) method will be updated if the component it came from is re-rendered.
57
+
58
+
However, that does not apply to elements that are found by traversing the DOM tree via the <xref:Bunit.IRenderedFragment.Nodes> property on <xref:Bunit.IRenderedFragment>, for example, as those nodes do not know when their root component is re-rendered. Consequently, they don’t know when they should be updated.
59
+
60
+
As a result of this, it is always recommended to use the [`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) method when searching for a single element. Alternatively, always reissue the query whenever you need the element.
61
+
62
+
#### Auto-refreshable FindAll() queries
63
+
64
+
The [`FindAll(string cssSelector, bool enableAutoRefresh = false)`](xref:Bunit.RenderedFragmentExtensions.FindAll(Bunit.IRenderedFragment,System.String,System.Boolean)) method has an optional parameter, `enableAutoRefresh`, which when set to `true` will return a collection of `IElement`. This automatically refreshes itself when the component the elements came from is re-rendered.
36
65
37
66
## Semantic comparison of markup
38
67
@@ -91,45 +120,6 @@ The semantic HTML comparer can be customized to make a test case even more stabl
91
120
92
121
Learn more about the customization options on the <xref:semantic-html-comparison> page.
93
122
94
-
## Inspecting DOM nodes
95
-
96
-
The rendered markup from a component is available as a DOM node through the <xref:Bunit.IRenderedFragment.Nodes> property on <xref:Bunit.IRenderedFragment>, as well as the `Find(string cssSelector)` and `FindAll(string cssSelector)` extension methods on <xref:Bunit.IRenderedFragment>.
97
-
98
-
The <xref:Bunit.IRenderedFragment.Nodes> property and the `FindAll()` method return an [AngleSharp](https://anglesharp.github.io/)`INodeList` type, and the `Find()` method returns an [AngleSharp](https://anglesharp.github.io/)`IElement` type.
99
-
100
-
The DOM API in AngleSharp follows the W3C DOM API specifications and gives you the same results as a state-of-the-art browser’s implementation of the DOM API in JavaScript. Besides the official DOM API, AngleSharp and bUnit add some useful extension methods on top. This makes working with DOM nodes convenient.
101
-
102
-
### Finding nodes with the Find() and FindAll() methods
103
-
104
-
Users of the famous JavaScript framework [jQuery](https://jquery.com/) will recognize these two methods:
105
-
106
-
-[`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) takes a "CSS selector" as input and returns an `IElement` as output, or throws an exception if none are found.
107
-
-[`FindAll(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.FindAll(Bunit.IRenderedFragment,System.String,System.Boolean)) takes a "CSS selector" as input and returns a list of `IElement` elements.
108
-
109
-
Let's see some examples of using the [`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) and [`FindAll(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.FindAll(Bunit.IRenderedFragment,System.String,System.Boolean)) methods to query the `<FancyTable>` component listed below.
An element found with the [`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) method will be updated if the component it came from is re-rendered.
124
-
125
-
However, that does not apply to elements that are found by traversing the DOM tree via the <xref:Bunit.IRenderedFragment.Nodes> property on <xref:Bunit.IRenderedFragment>, for example, as those nodes do not know when their root component is re-rendered. Consequently, they don’t know when they should be updated.
126
-
127
-
As a result of this, it is always recommended to use the [`Find(string cssSelector)`](xref:Bunit.RenderedFragmentExtensions.Find(Bunit.IRenderedFragment,System.String)) method when searching for a single element. Alternatively, always reissue the query whenever you need the element.
128
-
129
-
#### Auto-refreshable FindAll() queries
130
-
131
-
The [`FindAll(string cssSelector, bool enableAutoRefresh = false)`](xref:Bunit.RenderedFragmentExtensions.FindAll(Bunit.IRenderedFragment,System.String,System.Boolean)) method has an optional parameter, `enableAutoRefresh`, which when set to `true` will return a collection of `IElement`. This automatically refreshes itself when the component the elements came from is re-rendered.
132
-
133
123
## Finding expected differences
134
124
135
125
It can sometimes be easier to verify that an expected change, and only that change, has occurred in the rendered markup than it can be to specify how all the rendered markup should look after re-rendering.
@@ -178,3 +168,18 @@ This is what happens in the test:
178
168
8. Finally the last item in the list is found and clicked, and the <xref:Bunit.IRenderedFragment.GetChangesSinceSnapshot> method is used to find the changes, a single diff, which is verified as a removal of the second item.
179
169
180
170
As mentioned earlier, the `IDiff` assertion helpers are still experimental. Any feedback and suggestions for improvements should be directed to the [related issue](https://github.com/egil/bUnit/issues/84) on GitHub.
171
+
172
+
## Verification of raw markup
173
+
174
+
To access the rendered markup of a component, just use the <xref:Bunit.IRenderedFragment.Markup> property on <xref:Bunit.IRenderedFragment>. This holds the *raw* HTML from the component as a `string`.
175
+
176
+
> [!WARNING]
177
+
> Be aware that all indentions and whitespace in your components (`.razor` files) are included in the raw rendered markup, so it is often wise to normalize the markup string a little. For example, via the string `Trim()` method to make the tests more stable. Otherwise, a change to the formatting in your components might break the tests unnecessarily when it does not need to.
178
+
>
179
+
> To avoid these issues and others related to asserting against raw markup, use the semantic HTML comparer that comes with bUnit, described in the next section.
// This is intentionally in the order of most likely to minimize strategies tried to find the label
14
+
newLabelTextUsingForAttributeStrategy(),
15
+
newLabelTextUsingAriaLabelStrategy(),
16
+
newLabelTextUsingWrappedElementStrategy(),
17
+
newLabelTextUsingAriaLabelledByStrategy(),
18
+
];
19
+
20
+
/// <summary>
21
+
/// Returns the first element (i.e. an input, select, textarea, etc. element) associated with the given label text.
22
+
/// </summary>
23
+
/// <param name="renderedFragment">The rendered fragment to search.</param>
24
+
/// <param name="labelText">The text of the label to search (i.e. the InnerText of the Label, such as "First Name" for a `<label>First Name</label>`)</param>
25
+
/// <param name="configureOptions">Method used to override the default behavior of FindByLabelText.</param>
0 commit comments