Support UserAttributes in to all components

[huysentruitw]

I want to start testing a lot of components in my application with bUnit. A pattern I'm using (and a lot of others are using) for selecting elements is to use the data-testid attribute on elements you want to select instead of using a more complex query-selector. See also this post by Kent C. Dodds. It's also a best practice listed in the cypress docs

Proposal

My proposal would be to add a parameter TestId to MudComponentBase and to use that parameter to set the data-testid attribute on the first element of each component. I am open to create a PR for this.

Any other ideas are welcome, my example would be this, how to select the increment or decrement button giving this template:

<MudFab Color="Color.Secondary" Icon="@Icons.Filled.Remove" IconColor="Color.Primary" 
            Size="Size.Large" IconSize="Size.Large" DisableElevation="true" OnClick="Decrement"
            Disabled="Value <= MinimumValue || Disabled"/>
<MudFab Color="Color.Secondary" Icon="@Icons.Filled.Add" IconColor="Color.Primary"
            Size="Size.Large" IconSize="Size.Large" DisableElevation="true" OnClick="Increment"
            Disabled="Value >= MaximumValue || Disabled"/>

Alternatives I've considered

The alternative would be to use UserAttributes, but these are not implemented for all components and are also a lot more cumbersome to set (as we need to pass a dictionary).

[mikes-gh]

So we would need a data-testid attribute on all elements that are selected in tests?
I can see this separates the styling from the test selection but that sounds like a huge change.
Our styling classes are well named at the moment and shouldn't change hopefully.

[huysentruitw]

What would you suggest if there are multiple elements of the same type (buttons as in my example)? I'm currently adding a dummy class that I can use as selector, but it's a bit weird that there's no CSS for those classes.

[porkopek]

We already provide a Tag property in MudComponentBase. It's of type object, so you can attach whatever you want, and it has no other purposes. We never set it, so the user can do it.

Could it be enough for your purposes?

[porkopek]

I think I understood better now, and you want we pass that to every first element in the component.

Why not simply use .FindAll and you have an array and pick them by order?

[henon]

The alternative would be to use UserAttributes, but these are not implemented for all components and are also a lot more cumbersome to set (as we need to pass a dictionary).

You don't need a dictionary for UserAttributes. You can directly set them in the markup like this:

<MudButton data-testid="myButton"> ... </MudButton>

For the components who don't support them we'll just do so. It would be trivial for you to PR that.

[porkopek]

The alternative would be to use UserAttributes, but these are not implemented for all components and are also a lot more cumbersome to set (as we need to pass a dictionary).

You don't need a dictionary for UserAttributes. You can directly set them in the markup like this:

<MudButton data-testid="myButton"> ... </MudButton>

For the components who don't support them we'll just do so. It would be trivial for you to PR that.

Is there a guaranty that the first element will receive the UserAttributes?
I can't remember how @JonBunator managed this

[huysentruitw]

Ah, didn't know usage was so easy, that would definitely help for me. I will create a PR to add UserAttributes where it's missing.

[henon]

Is there a guaranty that the first element will receive the UserAttributes?

We have total control where the user attributes are applied. Look for @attributes="UserAttributes" in razor

[porkopek]

I know, but sometimes they are applied to the first element, others to the more convenient element.
I think @JonBunator changed that to uniformize it and be more consistent

[huysentruitw]

Yes, sometimes userattributes is passed to an underlying input element, which isn't really a problem for testing, as long as it's consistent.

I'm currently writing a test that uses reflection to get all MudComponentBase derivates and I then plan to use bunit to see if UserAttributes gets passed to an underlying element. Once we have this test, it would be impossible to forget about it when creating new components in future. But first, dinner 🍽

[huysentruitw]

I think I understood better now, and you want we pass that to every first element in the component.

Why not simply use .FindAll and you have an array and pick them by order?

Btw trusting on order is very error prone in UI tests. Specifically in this Up/Down component, the customer has already requested to swap the up/down buttons twice 😁 Changes like this may break the snapshot test but should not break any functional test.

[huysentruitw]

Test is starting to work:

Still have to get a trick out of my sleeve for generic components 😬

[JonBunator]

Is there a guaranty that the first element will receive the UserAttributes?
I can't remember how @JonBunator managed this

I only added missing Class and Style properties in my PR. I didn't know about the existence of the UserAttributes property at the time. Writing a bunit test which tests all components using reflection is such a great idea. Why didn't I come up with this haha.

[mikes-gh]

What about time picker for example or date picker. We test against many different sub-elements? We also loop through element arrays to test.

[huysentruitw]

O.M.G. This is way more work than I was thinking. I'm trying to get to the point where the test works, and we can improve from there.

[huysentruitw]

I have created a PR, which automatically tests all components for the forwarding of UserAttributes. However, you'll see that I had exclude a few components from my test because I don't know how to create them properly. Feel free to take a look at it. Meanwhile, I'm hungry again 😀

[huysentruitw]

My PR is finished. Now I only have to exclude 4 components, which are base components that we shouldn't test.

I also did a huge refactor and separated the component creation from the test itself, making things readable again (at least from my POV 😉). The MudComponentFactory could be extended to also add Style and Class parameters and reuse it for similar Style/Class testing.