Ensure LazyAssemblyLoader is mockable in testing

[egil]

Testing Blazor components that uses LazyAssemblyLoader is likely not going to be possible with bUnit without making it possible for the test to provide its own implementation of LazyAssemblyLoader as a mock.

Right now, the type is a sealed class, which will make mocking it hard (assuming this is the one that will ship in P8: .../Components/WebAssembly/WebAssembly/src/Services/LazyAssemblyLoader.cs - I did not find any other implementations while searching the repo).

Suggested solution - follow in NavigationManager's footsteps

Consider making LazyAssemblyLoader an abstract class, and with an abstract LoadAssembliesAsync(...) method. Then you can provide a sealed internal implementation which is used in production, and users are able to mock it during testing.

This works reasonably well with NavigationManager. Alternatively, expose the feature as an ILazyAssemblyLoader. This makes mocking even more intuitive for testers.

cc. @captainsafia

Related: bUnit-dev/bUnit#115

[captainsafia]

@egil Thanks for opening this issue! Can you share a sample of what the test would look like here and what overload you'd want on the lazy assembly loader?

[egil]

I can try (live coded on GitHub, mind the compiler errors):

Current situation (I think, dont have LazyAssemblyLoader locally to test)

// MyComp.razor
@Inject LazyAssemblyLoader AssmLoader
@code
{
  protected override async Task OnInitilizedAsync()
  {
     await  AssmLoader.LoadAssembliesAsync(new [] { "MyAssm.dll" });
  }
}

[Fact]
public void Test()
{
  using var ctx = new TestContext();
  ctx.AddSingleton<LazyAssemblyLoader>();

  // will this throw an exception from LazyAssemblyLoader because we 
  // are running in a test or have an undesired effect on the test because an assembly is loaded (again perhaps)?
  var cut = ctx.RenderComponent<MyComp>(); 
}

Proposal

public interface ILazyAssemblyLoader 
{
  Task<IEnumerable<Assembly>> LoadAssembliesAsync(IEnumerable<string> assembliesToLoad);
}

// MyComp.razor
@Inject ILazyAssemblyLoader AssmLoader
@code
{
  protected override async Task OnInitilizedAsync()
  {
     await  AssmLoader.LoadAssembliesAsync(new [] { "MyAssm.dll" });
  }
}

class MockLazyAssemblyLoader : ILazyAssemblyLoader
{
  public Task<IEnumerable<Assembly>> LoadAssembliesAsync(IEnumerable<string> assembliesToLoad)
  {
     // TODO ...
  }
}

[Fact]
public void Test()
{
  using var ctx = new TestContext();
  ctx.AddSingleton<ILazyAssemblyLoader, MockLazyAssemblyLoader>();

  // Now users have the option of controlling the loader and thus their test.
  var cut = ctx.RenderComponent<MyComp>();
}

[captainsafia]

@egil Thanks for sharing the example.

// will this throw an exception from LazyAssemblyLoader because we
// are running in a test or have an undesired effect on the test because an assembly is loaded (again perhaps)?

Running the lazy-assembly loader in test should be the same as running in a server context. In that scenario, we don't reload the assemblies, we just check that they have been loaded. We do this currently in our E2E tests.

I'm hesitant to implement a public interface here because we don't anticipate supporting arbitrary implementations of LazyAssemblyLoader and exporting an interface sets that expectation. We also don't anticipate that users will use the LazyAssemblyLoader in arbitrary components (it won't work predictably in that scenario).

I believe test cases shouldn't be affected here, but if you find other reasons for introducing an interface, let us know!

[egil]

@captainsafia thank you. I don't need it to be mockable if it works unobtrusively in a test setting.