Open egil opened 2 years ago
@SteveSandersonMS / @captainsafia: If you can think of a way for bUnit to run native dll's, I'd love to know.
As far as I can tell from the blog post announcing the feature, this is only works with Blazor WASM, and since bUnit works much more like Blazor Server from an runtime point of view, I get that it might not be possible.
It depends entirely on how a package containing the native dependency is authored. If the package author wants to support running in non-wasm scenarios too (e.g., Blazor Server), they can include Windows, macOS, and Linux versions of the native binary in the architecture-specific directories (https://docs.microsoft.com/en-gb/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders). In that case their package can also work on the OSes they've provided native dependencies for, and could therefore work under bUnit.
None of this happens automatically - it's up to the package author. If they don't provide native binaries for Windows, say, then the bUnit tests couldn't run on Windows.
@SteveSandersonMS so if a package author includes a native binary compiled for the OS that the bUnit test is running on, the [DllImport("Test")]
and @using System.Runtime.InteropServices
bits in users components will just work?
If that is the case, then I do not see anything in particular that bUnit can do to further add support for this, and it will be up to library authors/component developers to make it work.
Document the how native dependencies will work in a bUnit context.
Original issue text:
Components that use native dependencies cannot be rendered with bUnit.
Simple example (lifted from here):
Let’s add a simple native C function to a Blazor WebAssembly app:
dotnet workload install wasm-tools
dotnet test
yields the following error message:Options 1 - dont support it
For now, I am content with just telling users to wrap their extern calls in an abstract that they inject into the components that needs it, and then mock/fake that during testing.