bUnit-dev / bUnit

bUnit is a testing library for Blazor components that make tests look, feel, and runs like regular unit tests. bUnit makes it easy to render and control a component under test’s life-cycle, pass parameter and inject services into it, trigger event handlers, and verify the rendered markup from the component using a built-in semantic HTML comparer.
https://bunit.dev
MIT License
1.14k stars 105 forks source link

`System.MissingMethodException` after update to .NET 8 RC 2 #1239

Closed msynk closed 1 year ago

msynk commented 1 year ago

after updating to .NET 8 RC 2 our tests fail with the following exception:

System.MissingMethodException: 
Method not found: 'System.String Microsoft.AspNetCore.Components.CascadingParameterAttributeBase.get_Name()'.

Stack trace:

ComponentParameterCollectionBuilder`1.GetParameterInfo[TValue](Expression`1 parameterSelector)
ComponentParameterCollectionBuilder`1.Add[TValue](Expression`1 parameterSelector, TValue value) line 51
msynk commented 1 year ago

I think the issue is coming from this line:

https://github.com/bUnit-dev/bUnit/blob/2afd487f2a0b8579de5bb4ca1b82aaf7e678361d/src/bunit.core/ComponentParameterCollectionBuilder.cs#L442

and the fact that the CascadingParameterAttribute now has a base class named CascadingParameterAttributeBase in .NET 8 RC 2

egil commented 1 year ago

Hmm interesting. Wonder why our own tests haven't caught this. Can you provide an example of a test that causes this. Should be a pretty easy fix though, so we should be able to get a fix out soon.

linkdotnet commented 1 year ago

Even with the new introduction of the new base class, that shouldn't much interfere with the usage.

As @egil mentioned, it would be really helpful to have a minimal reproducible example for us. We have many tests in combination with cascading parameters and not of them experienced such an exception.

msynk commented 1 year ago

here is the sample repo: https://github.com/msynk/bUnitNet8RC2

It seems this exception throws only for the components with parameters.

linkdotnet commented 1 year ago

Interesting - the same test passes when moved inside our test suite.

msynk commented 1 year ago

@linkdotnet really interesting. I've run the tests in both stable and preview versions of bUnit (1.23.9, 1.24.3-preview) with the same results.

linkdotnet commented 1 year ago

Sorry - I meant I moved the test inside the bUnit code and let it run there. No issue at all. Even if I check out 1.23.9 and let the test run.

egil commented 1 year ago

Is it a mstest thing?

linkdotnet commented 1 year ago

Thought so too and "migrated" the given example to xUnit with the same outcome - still failing tests with the given exception.

linkdotnet commented 1 year ago

With 1.22 (where we don't explicitly support net8.0) it works like a charm (which makes sense given the context).

egil commented 1 year ago

Doing a new preview release now that will build against RC2. Perhaps that fixes the issue. Guessing the package on nuget.org is build against rc1 and that is causing the failure. We cannot replicate when adding the tests and running against bunit sources.

linkdotnet commented 1 year ago

Ah fair - I also run rc.2 locally. But that bit is anyway interesting. Why should it fail with a type that is provided by the framework and not us.

egil commented 1 year ago

Upgrading to <PackageReference Include="bunit" Version="1.24.8-preview" /> fixes the problem for me.

egil commented 1 year ago

Ah fair - I also run rc.2 locally. But that bit is anyway interesting. Why should it fail with a type that is provided by the framework and not us.

Guessing it is because rc1 and rc2 are not binary compatible.

linkdotnet commented 1 year ago

Okay - @msynk can you confirm that it also works on your side?

msynk commented 1 year ago

@linkdotnet Thanks a lot. the latest preview version (1.24.9-preview) is working fine for me 👏.

linkdotnet commented 1 year ago

Nice!