Dummies

A dummy component is a component that simply replaces another component in the render tree, but does nothing else besides that, i.e. no rendered output of any kind.

Minimum requirements include:

1. Capture paramters passed to the original component it replaces. This is supported through the [Parameter(CaptureUnmatchedValues = true)] feature in Blazor.
2. Expose captured parameters for assertion.
3. Expose what component it has replaced

This implementation does the above.

public class Dummy<TComponent> : ComponentBase
{
  [Parameter(CaptureUnmatchedValues = true)]
  public IReadOnlyDictionary<string, object> Parameters { get; set; } = default!;
}

We need an extension method that makes it easy to set up a replacement of a component with the dummy. My current suggestion is AddDummyFor<TComponent>().

I think Dummy is the correct term to use for the extensions method. It makes sense to use AddDummyFor because it acts on a collection, but from an outside view, it does not describe which effects this adding will have. It could maybe be RegisterDummyFor, InjectDummyFor, ReplaceWithDummy, or ReplaceInstancesWithDummyFor.
I don't have any specific preferences so I'm just spit-balling some of my thoughts. AddDummyFor is also a fine name if that fits the naming of similar extension methods.

Another thing that might be useful to add could be to be able to use a base class or interface if you have a group of components that you don't want to test in the current cut.

It could maybe be RegisterDummyFor, InjectDummyFor, ReplaceWithDummy, or ReplaceInstancesWithDummyFor.

Yeah, I am not sure about the name either.

Another thing that might be useful to add could be to be able to use a base class or interface if you have a group of components that you don't want to test in the current cut.

That should already be possible with the base functionality made available with the IComponentDoubleFactory. The CanDouble(Type componentType) method would simply inspect the base class or namespace of componentType and say return true if they match whatever base type or namespace you want to double.

Cool. I can imagine using that. 👍

Thinking about simply calling these things IComponentFactory and then giving the collection property on TestContext the name ComponentFactories. It seems more close to what it actually is, e.g.:

public interface IComponentFactory
{
  bool CanCreate(Type componentType);
  IComponent Create(Type componentType);
}

And an example factory that creates a Dummy<T> component:

public class ComponentDummyFactory : IComponentFactory
{
  private readonly Type componentToDouble;
  
  public ComponentDummyFactory(Type componentToDouble)
  {
    this.componentToDouble = componentToDouble;
  }
  
  public bool CanCreate(Type componentType)
    => componentType == componentToDouble;
  
  public IComponent Create(Type componentType)
    => (IComponent)Activator.CreateInstance(typeof(Dummy<>).MakeGenericType(componentType))!;
}

public static class ComponentFactoriesExtensions
{
  public static ICollection<IComponentFactory> AddDummyFactoryFor<TComponent>(this ICollection<IComponentFactory> factories)
  {
    factories.Add(new ComponentDummyFactory(typeof(TComponent));
    return factories;
  }
}

And here is it used in a test:

using var ctx = new TestContext();
ctx.ComponentFactories.AddDummyFactoryFor<MyChildComponent>();

var cut = ctx.RenderComponent<MyParentComponent>();

Assert.Empty(cut.FindComponents<MyChildComponent>());
Assert.NotEmpty(cut.FindComponents<Dummy<MyChildComponent>>());

ctx.ComponentFactories.AddDummyFactoryFor<MyChildComponent>();

This looks great. Conveys that this will create dummies using the "factory" for this specific type.

public interface IComponentFactory
{
bool CanCreate(Type componentType);
IComponent Create(Type componentType);
}

This also opens up for potentially creating other types of factories in the future. Like a factory for a generic mocked component or something like that.

Another alternative is to use the name TestContext.ComponentCreationRules and have a concept of IComponentCreationRule.

Then the vocabulary could be e.g.:

ctx.ComponentCreationRules.AddDummyFor<TComponent>()

... or perhaps

ctx.ComponentCreationRules.ReplaceWithDommy<TComponent>()

It's pretty wordy thought, but makes it very obvious what is going on.

Or maybe

ctx.ComponentCreationRules.UseDummyFor<TComponent>()

Which also has wording like a rule: "For this type use dummy"

ComponentFactories is good.

Also consider

ComponentFactories.Register()
ComponentFactories.Register(type)

And also overrides that accept a Func<T, IComponent> parameter

Thanks for the input Peter.

ComponentFactories.Register()
ComponentFactories.Register(type)

I think the convention in .net is to use Add for collection like types, or?

And also overrides that accept a Func<T, IComponent> parameter

Can you elaborate on how this would work?

I'm just thinking that if you had a base factory built in that just returned a stub IComponent then you could use ComponentFactories.Stub()

The Register suggestion was along a similar line, but where it would return what the coder specified rather than a stubbd IComponent - the purpose here being that we don't have to write a factory for each component type we want in there.

ComponentFactories.Stub(); => Mocked IComponent that does nothing
ComponentFactories.Register<ChildComponent, SomeTypeThatImplementsIComponent>();
ComponentFactories.Register(User supplied Func that returns IComponent)

@mrpmorris, I think I get what you are saying.

What I am thinking currently is having base functionality added to TestContext, that allows for me and others to provide helper methods/extensions, that enables the mocking/faking/stubbing/etc.

So something like this will be added to bUnit.core:

public interface IComponentFactory
{
  bool CanCreate(Type componentType);
  IComponent Create(Type componentType);
}

public interface IComponentFactoryCollection : IList<IComponentFactory> { }

Then this property will show up in TestContextBase:

IComponentFactoryCollection ComponentFactories { get; }

And then we and others can create extensions methods on IComponentFactoryCollection that match the vocabulary they like, e.g. UseStubFor<TComponent>() or Register<TComponent, TReplacementComponent>().

I am leaning to wards calling the new property in TestContext for ComponentFactories since that is in essence what is being exposed, a collection of component factories that will be used when rendering components using bUnit.

The naming of the extension methods that build on this functionality I am still not sure of. In theory, these extension methods could be on TestContext, e.g.:

using var ctx = new TestContext();
ctx.UseStubFor<TComponent>();
// ...

It's seems the current documentation is not updated, this feature is a must to have,thank you all for all the effort you've made. unfortunately I don't find a way to use it.
Is the extension method located in a particular nuget package version?

Hey @ChristopheDEBOVE,

Thank you, and thanks for your support!

The feature is in the preview release of bUnit you can find on nuget.org. I'm going to document it soon after releasing it/going out in a non preview package.

There might still be done changes to the feature coming based on feedback, so that's why I'm holding off on the docs for now.

@egil Thank you I found it. very valuable feature !!!

Btw. Here is an example for using the built-in component factories in bUnit: #450 (comment)