hack-example Branch is working => so far

[GeorgeS2019]

https://github.com/fledware/GodotXUnit/tree/hack-example
Godot Version: 3.3.rc7.mono
Windows 10:

Step 1

GodotProjectName.csproj

<Project Sdk="Godot.NET.Sdk/3.3.0">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <LangVersion>8.0</LangVersion>
    <RootNamespace>GodotProjectName</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="xunit.runner.utility" Version="2.4.1" />
  </ItemGroup>
</Project>

Step 2

GodotProjectName.dll

• GodotFactAttribute.cs

    [XunitTestCaseDiscoverer("GodotXUnitApi.Internal.GodotFactDiscoverer", "GodotProjectName")]
    // ReSharper disable once ClassWithVirtualMembersNeverInherited.Global
    public class GodotFactAttribute : FactAttribute
    {
    }

Known issues

• Visual Studio 2019 debug tests no longer work => suggestion??

Benefits

• One single csproj project managed by Godot mono build tool.
• Simplicity of .NET5 SDK project format.

[rexfleischer]

Thanks for testing this! This is definitely the way to go for the new build system if people are ok with having the test assets in with the same assembly. I agree with the benefits here. Maybe there should be a second release that is for single project builds?

Visual Studio 2019 debug tests no longer work

Did they ever work? I've never been able to get it to work.

[GeorgeS2019]

@rexfleischer I can get the Xunit [Fact] tests of GodotXUnit of the master branch to work in VS2019. But now, no more. Not sure why.

[GeorgeS2019]

@rexfleischer Still, we need to figure out the productive way TO DO WHAT SHOULD Be ROUTIME, unit and integration testing in Godot for c#.

[knightofiam]

I've got this setup working for the hack-example branch in JetBrains Rider 2021.2.1, Godot 3.3.3.stable.mono, & macOS Big Sur 11.6.

@GeorgeS2019 Thank you! Failed to get it working for several hours before I found your solution.

[derkork]

I have this setup working within Rider 2021.2, Godot 3.3.3 and Windows. After I have patched the Rider test runner to work with GodotXUnit I can even run tests directly from Rider. I wasn't able to get the main branch working but the hack-example branch is a lot easier to set up and works. I can now run tests from the IDE and the Godot editor and thanks to GodotXUnit having a CLI runner I also have a CI solution. I think this is really the way to go. I'm not quite sure why you would need to have this multi-project setup, @rexfleischer could you maybe elaborate on that?

[derkork]

In case you also want to patch the Rider test runner, these are the lines to change:

namespace RiderTestRunner
{
    // ReSharper disable once UnusedType.Global
    public class Runner : GodotTestRunner // <--- here
    {
        public override void _Ready()
        {
            GDU.Instance = this;  // <--- and here
            var textNode = GetNode<RichTextLabel>("RichTextLabel");
            foreach (var arg in OS.GetCmdlineArgs())

[rexfleischer]

@derkork There are a couple reasons this has to be in multiple projects (although, I wouldn't mind being proven wrong if I am!):

• the XunitTestCaseDiscoverer requires the assembly name to be included. Unless there's a way to tell it "this assembly", I'm not sure what can be done about that. So, this separated the assembly so I can hardcode the assembly name without having the assembly with the tests required to change the name.
• Having a separate project will lower the size of the game by not including the xunit and runner deps.

If these are incorrect, please let me know.
Also, I really like the RiderTestRunner you did. Where can I find docs on this? The few quick searches I did just sent me to unity.

[derkork]

The Rider test runner is actually written by @van800 who also maintains the Godot plugin for Rider. I have just patched it up so that it skips the GodotXUnit runner but still initialized the GDU object. The original can be found at https://github.com/van800/godot-demo-projects/tree/nunit/mono/dodge_the_creeps/RiderTestRunner . You need to put this into your project, but the Godot plugin for Rider will actually tell you this when you try to execute tests without having it.

As for the patching of the assembly name, thats a sort of unfortunate design of xUnit to not allow to add a discoverer programmatically. I wonder if this would work:

• the GodotXUnitApi packages is available on nuget and also has dependencies on xunit / xunit.runner.utility and Newtonsoft.Json
• the GDI/GDU/GodotXUnitRunner classes move out of the GodotXUnitApi thing and remain part of the Godot addon, so no direct Godot dependencies
• Installation works like this
  • Install the Godot Addon
  • Open the Solution in the IDE, download the GodotXUnitApi package from Nuget, this also pulls transitional dependencies.

This way GodotFact and the discoverer are always in the same assembly and and you don't have to manually patch the assembly name. Drawback - the project will probably not compile until you pull those dependencies from Nuget.

Alternatively, the plugin could probably do a quick search/replace over GodotFact.cs and patch in the current assembly name on plugin start if it is wrong. That is probably only a few lines of code.

Then the only thing remaining is the additional classes that you pull in that you don't need for runtime, but I'm not sure if this is really that big of a deal. One could also maybe wrap the CS-classes in some #if !RELEASE or something like this, so for a release build you could set a RELEASE preprocessor flag and the classes would disappear.

[van800]

I have once written an explanation on how Rider runs tests inside godot game, please see JetBrains/godot-support#58

[rexfleischer]

@derkork I was able to get master working again with multiple projects. I still really like the idea of of putting the GodotFact and whatnot into a separate dll. I tested it on my game and it worked just fine, but only in the godot editor. Good stuff with the #if !RELEASE stuff, I didn't know about that and that seems to be the way to go.

@van800 Thanks, that link is very helpful. I moved both those files into the directory, and I was able to get tests running and passing. The only problem I've found is when the test tries to change the scene. It seems like when the scene gets changed, it will just never recover and the runner script goes away. If I have time, I'll be happy to look into this.

Also, would it make sense to search for the scene with addons/**/RiderTestRunner/Runner.tscn, and whatever is found first is the runner? That way any addon can setup their own way to hook into the RiderTestRunner without having to add addon code outside of the addon directory. If I get back to godot full time again, I was probably going to make a similar test integration for kotlin, because that is by far my preferred language. But following that pattern, it would be awesome to have a godot addon that can hook into multiple test runners by this type of convention.

[rexfleischer]

Following a lot of what @GeorgeS2019 did, this brought me to this PR: #10

I merged it and will have a release on the addon site tonight.

[rexfleischer]

What I've got so far for the RiderTestRunner is at: https://github.com/fledware/GodotXUnit/tree/rider-test-runner

[van800]

That's cool, thank you!

1. Except the mentioned trick to use #if RELEASE, there is also another one to use conditions in the csproj like:

<Compile Include="RiderTestRunner\Runner.cs" Condition="'$(Configuration)' == 'Debug' " />

As a plus, when you switch SolutionConfiguration in the IDE it would show you actual files included

2. Yes, Godot Support plugin can search for RiderTestRunner/Runner.tscn in the multiple locations. But I would rather throw error in case multiple runner are found. Would it be fine with you?