Blazor - How to manually load a component

[chanan]

@SteveSandersonMS: I was talking to @danroth27 in the Gitter room and he suggest I open a Github issue and ping you on it.

We are working on a test renderer for Blazor. We have a POC working: https://github.com/egil/razor-component-testing-library

It currently takes a Component class runs and using the StringRenderer gets the string for a compare inside of a xunit Fact.

I thought it would be better to have it work more like react Jest snapshot testing (https://jestjs.io/docs/en/tutorial-react#snapshot-testing).

Basically:

1. Run a tool (console app / dotnet global / whatever)
2. Point it at "something" - that could be .razor file/ C# class / compiled .dll (or combo of the above)
3. Run that thing and get the string as we already have working in the POC
4. Save string to .snapshot file if first run or update flag
5. If .snapshot file already exists compare the string as in the POC

We are stuck on step 2 & 3 - My thought was can I take a razor file and compile it myself into a DLL?

(Also, I have another use case for wanting to do that anyway)

[SteveSandersonMS]

Point it at "something" - that could be .razor file/ C# class / compiled .dll (or combo of the above)

You should use the component type that has already been compiled into the assembly you're testing.

[chanan]

Do you mean use reflection to find all the components in the compiled assembly and use the renderer to run them?

[SteveSandersonMS]

I assumed the unit test code would already be referencing the compiled types as part of defining the test logic.

It's not generally interesting to just run all of the components in an assembly without any further custom logic. You'd likely want to pass different parameters to them, as well as simulate events occurring on them. Doing this means writing specific test cases for each component, so I'd imagine that defines exactly which components you're testing.

[chanan]

The way you are describing it, we already have working in the project: https://github.com/egil/razor-component-testing-library

For example:

[Fact]
        public void Component1Test_1()
        {
            var expectedHtml = @"<div class=""my-component"">
                                     This Blazor component is defined in the <strong>ComponentLib</strong> package.
                                 </div>
                                 ";

            var result = Component<Component1>().Render();

            result.ShouldBe(expectedHtml);
        }

What I am trying to do is make it so you dont need to define a [Fact] or [TestMethod] for mstest but instead define a test project where you have the components exactly the way you want them

So if you are testing MyButton then have a component file:

Hello

Grab that and run it automatically (From lets say: dotnet snapshot-testing my-path-to-test-project) - then grab all those .razor files or compiled class - and snapshot them.

Not sure yet if its a good idea or not, and you mentioned events - not sure what to do about that either yet. Based on what you mentioned before, I think I can load a .dll and using reflecton find all class that inherit from ComponentBase and run them through the StringRender - maybe...

[egil]

@SteveSandersonMS thanks for input.

I think we can do what @chanan wants already, I just need to tweak and add support for snapshotting, I'll add some prototype code for that the coming days.

What would be great to get your input on is a way render a component with initial params (works already) and then modify it by updating it's params or by triggering events it listens to, and after that get the final HTML. That should enable a way to test a component in it's different states.

More discussion over on the prototype repo: bUnit-dev/bUnit#1

[SteveSandersonMS]

Good, sounds like the question is answered so I'll close.

What would be great to get your input on is a way render a component with initial params (works already) and then modify it by updating it's params or by triggering events it listens to, and after that get the final HTML. That should enable a way to test a component in it's different states.

See our unit tests. There are loads of them that do that.

[egil]

Good, sounds like the question is answered so I'll close.

What would be great to get your input on is a way render a component with initial params (works already) and then modify it by updating it's params or by triggering events it listens to, and after that get the final HTML. That should enable a way to test a component in it's different states.

See our unit tests. There are loads of them that do that.

Fair enough @SteveSandersonMS.

I've seen some of your tests. I found some that rendered to a string and based my current effort on the ideas in those (using HtmlRenderer). I've also seen some of the others that does indeed get a ref to the component under test, modify it and do on-clicky things. However, they were quite hard to comprehend, maybe due to my limited understanding of the render logic.

I also remember trying to duplicate your tests locally to get a better understanding of what is what, but think that failed, since some of the needed classes to setup and run them are/were marked internal.

UPDATE: I checked again, and now I remember being unable to find a nuget package that has the test helpers that you are using in your tests (https://github.com/aspnet/AspNetCore/blob/v3.0.0-preview7.19365.7/src/Components/Shared/test/)

It would be a huge help if you make just a single unit test sample with comments that show what happens where, what infrastructure to set up and how, so we have something as simple as possible to built on.

Thanks, Egil.