Does anyone have an example unit test project?

[symbiogenesis]

There isn't too much info online about how to write unit tests directly for .NET MAUI when using the single-project style.

I know that you could try to move most of your code into a .NET Standard project and then test that way.

However, is there any easy way to test a .NET MAUI project itself? In order to do so, the test project would need the same target framework as the MAUI project.

I was able to add a regular net7.0 target, alongside the native targets, and then test that way. But it had caused a lot of glitches with Visual Studio. Can't even run and debug the app via Visual Studio after doing that. Works that way when running from the CLI, but I like using VS.

[JohnHDev]

You can't currently run unit tests against .NET Maui app projects, but you can run unit tests against .NET Maui library projects. It is a flaw in the design and I believe they are looking to correct that in .NET 8.

[symbiogenesis]

Does anyone have a link to the open issue?

[symbiogenesis]

It occurs to me that reverting to the old multi-project style could also work.

Given all the little papercuts and overly magic use of implicit nuget references, I actually prefer the old Xamarin.Forms style project structure.

[JohnHDev]

Does anyone have a link to the open issue?

#3552

It's closed against .NET 8 apparently. Don't think it has been back ported to .NET 7 (you know, the current production release we are all using, thanks MS...)

[JohnHDev]

It occurs to me that reverting to the old multi-project style could also work.

Given all the little papercuts and overly magic use of implicit nuget references, I actually prefer the old Xamarin.Forms style project structure.

I wouldn't, if that stopped working for any reason the chance of it being fixed is next to nil. MS is all about the new and shiny...
Options right now are to create a new Unit test project for .NET7, reference your .NET Maui library project and then create your tests. Im using Moq for any dependencies etc.

[Xyncgas]

Whenever I see people testing their software, I am confused because if you understand 1 + 1 = 2 and you wrote it in code why are you testing whether if it's true, if you are testing you didn't write 1 + 2, that means testing actually is unnecessary as long as you are so good at programming.

[JohnHDev]

I am unsure what point you are trying to make here, but most professional software firms expect/demand unit tests. This is a basic requirement that Maui cannot do with app projects, and is a serious flaw that they have addressed in .NET 8. Please don't troll those of us that disagree with you.

[Xyncgas]

to be constructive, I suggest an alternative approach to current UI testing that imo we should embrace : let's check whether you write 1 + 2 via the type system, dependent types & self proofing system, if the UI is written in F* for example, I say it's unnecessary to use current methods of UI testing

[symbiogenesis]

That is not a helpful critique. C# is not a language with dependent types or theorem proving, and even if you were using that, then you are arguably just using an alternative type of unit testing.

And what I really was meaning is to ask about testing in general, including integration testing. Having a working example of any kind of test project that references a MAUI app would give me the ability to write any kind of tests.

Such testing is extremely practical in large codebases, with dependencies and evolving requirements and concerns, and unexpected edge cases that you might not have even thought to consider in a formal specification.

If a nuget update breaks feature 362 out of 754 that would be good to know in the build pipeline, rather than in production.

If changing how a screen works, or how a workflow operates, it is important to know if failures occur after such a refactor. It is easy to break some other feature unintentionally, even if the crux of your refactor is successful.

Coded UI testing (selenium style) is also key, if there are bugs in MAUI or the .NET Framework, that only show up on a particular platform, or only in Release mode but not Debug mode. Or if all of the ViewModels have perfect logic, and the screens are all binding to valid properties, but it is simply that they are bound to the wrong properties for the use case.

[symbiogenesis]

Since F* compiles down to F# it might be possible to get it to play nicely with .NET

But I have barely ever seen anyone use even F# with MAUI. There are some examples online, however.

If you wanted to build a simple MAUI app with F* then you could maybe win me over as a convert.

[symbiogenesis]

Do you have a sample code repo of a MAUI app written in F* ?

[BretJohnson]

@symbiogenesis - Can you say more about this - about the problems you saw doing this?

I was able to add a regular net7.0 target, alongside the native targets, and then test that way. But it had caused a lot of glitches with Visual Studio. Can't even run and debug the app via Visual Studio after doing that.

This worked for me, in my very simple test case. And it's what's suggested here: https://cedricgabrang.medium.com/adding-xunit-test-to-your-net-maui-project-ee36c00a8542.

I'm not suggesting this is the ideal solution - and #3552 in .NET8 will help. But I'd like to understand better what breaks with this today for you in VS. There might a tooling bug we should investigate, for instance. Thx.

[marcos-marimon]

Hi there!!
I am facing the same problem here, trying to test .NET Maui library projects. The solution from Cedric Brang does not work in my case. On the one hand, I cannot set my library projects with the target net6.0 as they leverage lots of nugets, all of them incompatible with net6.0, and on the other hand, what happens with all the native code?
Has anybody found out a solution for these issue?
Thanks in advance!

[mackayn]

Suggested workaround doesn't work, after tweaking a plugin and some platform code, you can't deploy to device or sim to debug although everything compiles ok.

[mackayn]

Actually after a full clean and physically delete obj & bin and restart VS and recompile, the main project can be built as a dll and be referenced by the test project, you will have to make sure any platform code is in a platform switch, thankfully almost all of the platform code is separated in this large app but if you have a lot of platform code without conditional compilation you will be busy before you can build against .NET8. I'll update here is XUnit and Moq and Fluent Assertions all play nice in MAUI but I'm sure they will.

[MartyIX]

There is now: https://learn.microsoft.com/en-us/dotnet/architecture/maui/unit-testing and it seems to allow directly testing .NET MAUI (C#) projects.