Throwing exceptions in FindComponent.

[stevenbey]

I have a number of tests where I am testing that child components are not rendered (i.e. they're only rendered under certain conditions). In this situation I would expect to use Assert.Null; however, I am having to use Assert.Throws, which I think is semantically inappropriate. Is there a reason why the exception is being thrown, rather than returning null?

PS bUnit is AWESOME!

[egil]

Hi Steven,

I am not fan of returning null unless there is a clear indication that the method will do that, e.g. as with TryFindComponent.

What you can do instead is to use FindComponents instead, which returns a list of components found. Then your assertion will be Assert.Equal(0, cut.FindComponents<XXXX>().Count).

[egil]

True. I am using FluentAssertions at work, so wouldnt know :)

[stevenbey]

Sorry to bother you but, even though I've been using your recommendation, I still feel that this is semantically inappropriate. I've created an extension method called HasComponent and test it with Assert.False (or equivalent). Would it be possible to add this to bUnit? I appreciate that this would be very low priority but it's extremely trivial to add and would make the library more comprehensive for all developers.

[egil]

No need to be sorry, and thanks for the suggestion.

I have been thinking about building custom assertion methods like the one you mention, however, I am a bit wary of it, since there are numerous assertion libraries out there, and custom assertions methods would be unlikely to be compatible with all the assertion libs and assertion styles' vocabulary.

E.g. if I was to build something for FluentAssertions, the style would be cut.Should().HaveChildComponent<TComponent>(). For xUnit's built-in assertion library, it would probably be Assert.HasChildComponent<TComponent>(cut).

There are a few basic assertions built-in, specifically the MarkupMatches and a few other assertion methods related to the semantic comparision feature of bUnit.

So, short answer is probably no, I would not want to build it into bUnit.web/bUnit.core.
BUT, it there could be an bunit.assert.xunit/bunit.assert.fluentassertion/bunit.assert.nunit project in the future, that has assertions in the future.

[stevenbey]

I've confused things by mentioning the Assert.

What I should have said is that using FindComponents is semantically inappropriate when the intention is to simply determine whether the CUT has the given child component (i.e. I don't need the list that is returned). It's similar to the principle of not returning a null value from a method: as you've said, in that situation you would prefer to define a TryFindComponent method. Therefore, in this situation, I think a HasComponent method would be better.

I'm sure that the Master/Details scenario that I'm testing against would be quite common, so this would be appropriate for other developers.

For example:

public static bool HasComponent<TComponent>(this IRenderedFragment renderedFragment) where TComponent: IComponent
{
    return renderedFragment.FindComponents<T>().Count != 0;
}

Assert.False(cut.HasComponent<Details>());
// or 
Assert.True(cut.HasComponent<Details>());

[egil]

Ahh yes, that might make sense. Can you create an issue for this with a design suggestion. And if you want to submit a PR, even better :-)