Adding TryFind to RenderedFragementExtensions

[kylesiopiolosz]

Would there be any opposition to adding the following method to the RenderedFragmentExtensions?

public static bool TryFind(this IRenderedFragment renderedFragment, string cssSelector, out IElement? element) {
  element = null;
  try
  {
    element = renderedFragment.Find(cssSelector);
    return true;
  }
  catch
  {
    return false;
  }
}

I find these sort of TryDo methods nicer to work with and keeps the test cases that are being written cleaner, especially if you're testing for the presence / absence of a particular element.

[linkdotnet]

Hey @kylesiopiolosz,

Thanks for suggesting a new functionality. Can you describe your use case or problem you solve for such a function?

I am asking that because I am not sure what would change. Currently Find throws directly an exception with a meaningful message. Introducing something like TryFind would lead to branching in your test. Whether or not this is good is a different question. nevertheless, in the case where you would not find the element, you most probable would have something like Assert.Fail("Some meaningful test").

If this is the case, I am not sure if a general-purpose function like TryAdd would bring lots of benefits or if it's better placed as an extension method inside your project to make that work.

[kylesiopiolosz]

So in my case I have a toggleable character count that appears below a text area component that I wrote. I wanted to write a quick unit test to assert the presence or absence of the element. Something like:

        IRenderedComponent<TextArea> component = context.RenderComponent<TextArea>(parameterBuilder =>
        {
            parameterBuilder.Add(p => p.ShowCharacterCount, showCharacterCount);
            parameterBuilder.Add(p => p.MaxLength, maxLength);
        });

        var characterCountFragmentFound = component.TryFind("[SELECTOR]", out var characterCountFragment);

        if (showCharacterCount)
        {
            Assert.IsTrue(characterCountFragmentFound);
            Assert.AreEqual($"{maxLength} character(s) left", characterCountFragment?.InnerHtml);
        }
        else
        {
            Assert.IsFalse(characterCountFragmentFound);
        }

In this way I didn't have to wrap the call to Find in a try/catch block and explicitly handle the ElementNotFoundException.

[linkdotnet]

Thanks for providing your example.

I assume the variables you pass in are from a data driven test?

Now I am no expert on testing, but I do think splitting this test into two would help you twice:

it would make the intent clearer as well as getting rid of the TryAdd functionality. At least it seems that you want two different things here and it is just comfortable to use such a function to remove the setup code.

With that in mind, I don’t see fit for such function for a broader audience. I do believe though that is totally fine to have such function as a extension inside your own project.