how to specify which component to use with UseDummyFor and why using it at all when one can call the methods from Instance without UseDummyFor

[OuttaSpaceTime]

Hey,

I did some testing with UseDummyFor now. Some problem I encountered with this approach was, that I was not sure how to specify for which element I want to use the dummy for.

So for example in my project I have pages with several dropdowns for example two times RadzenDropown<String> and two times RadzenDropdown<Skill>.

Now when I call ctx.ComponentFactories.UseDummyFor<RadzenDropDown<String>>(); and try to find it with var dummy = cut.FindComponent<Dummy<RadzenDropDown<String>>>(); I am not sure which one was found. I except it is the first within my RenderTree but how do I get the second now?

I tried something like cut.FindComponents instead of `FindComponent, but it isn't working at all.

With further experimenting I noticed that this also works instead of using the dummy for triggering the method:

var skillcomponent = cut.FindComponent<SkillComponent>(); 
skillcomponent.Instance._selectionType = "\u25A1";
await skillcomponent.InvokeAsync(() => skillcomponent.Instance.OnShowSelected(""));

_selectionType is the binded value for my dropdown.

So why should I use the dummy in the first place then? One counterside is that I have to make some properties public for using the above code, but it doesn't seem too dramatic in my point of view but might leave more opportunity for tightly coupled design. Might there also be a possibility to access these within tests without having to make them public at all?

Thanks in advance,

Felix

[egil]

I tried something like cut.FindComponents instead of `FindComponent, but it isn't working at all.

var dummy = cut.FindComponents<Dummy<RadzenDropDown<String>>>(); should work like it normally does. FindComponent will find the first component in the component tree that matches the type, where as FindComponents will find all.

So why should I use the dummy in the first place then? One counterside is that I have to make some properties public for using the above code, but it doesn't seem too dramatic in my point of view but might leave more opportunity for tightly coupled design. Might there also be a possibility to access these within tests without having to make them public at all?

Component factories are especially useful if you have a 3rd party component in your render tree that you want to replace with something else to make testing easier. Some components have dependencies on things like services, JSInterop, or specific cascading values, that can make it hard or impossible to set up a test of a component that uses them. With factories, you can simply remove them from the component tree and not render them at all.

With my own components, I would almost never go through the Instance property and call methods or access properties on the component instance directly, since that is not what the user is doing from the browser. Instead, I would use the users way to triggering methods, i.e. the onXXX event handlers. The one exception is when a component has [JSInvokableMethod] methods, which you as a tester can call directly, as your JavaScript would otherwise do.

Hope this makes sense.

[OuttaSpaceTime]

Ah okay you are right cut.FindComponents<Dummy<RadzenDropDown<Skill>>>(); works now, I must have had some stupid mistake with this last time.

Also the rest makes perfect sense, thanks for the clarification!

I think it might be worth to be covered in documentation with some good code examples.

[egil]

yeah, documentation is coming once the feature is not in preview any more. still considering dumping UseDummy and simply keeping UseStub, since more people will recognize the concept of a stub from testing terminology.