Puppeteer
Emperor
There seem to be three popular-ish unit testing frameworks: xUnit, NUnit, and MSTest. I've only poked at xUnit and not touched the others so far. And really I was using xUnit as my own shortcut to compile and run libraries and not as proper unit tests. `dotnet test` is pretty easy to compile a DLL and run some commands with it.
One really weird thing about unit testing I just learned today is: Godot seems to compile with the .NET Core 3.1 or .NET v5 SDK and run with the Mono CLR. I have no idea if that impacts how we should run unit tests.
Subprojects using the non-Godot SDK reference in their csproj files should be unit testable if we move them off of netstandard targets (because netstandard is more of a virtual compatibility target than an actual platform). For any projects using the "Godot.NET.Sdk/3.3.0" Sdk attribute I have yet to figure out how to unit test those.
As for integration testing, I currently have no idea how to begin. All my Google results so far for Godot integration testing talk about the difference between unit and integration testing then explain unit testing in detail and seem to forget entirely about integration testing after that. This issue's comments may hold some value, but no silver bullet jumps out.
@WildWeazel , how does Unity handle integration testing? Do you just avoid testing graphical routines, or is there some sort of testing harness?
All that said, this is not a huge near-term goal. It's difficult to make unit tests when we have no design by contract and all the data structures are in rapid flux. But simply executing the load or save game code and making sure it doesn't crash might be a worthwhile unit test that won't blow up if the code changes. The SAV, BIQ, and media readers might could use some unit tests as their methods, inputs, and outputs shouldn't change much if at all other than to gain new code to test.
One really weird thing about unit testing I just learned today is: Godot seems to compile with the .NET Core 3.1 or .NET v5 SDK and run with the Mono CLR. I have no idea if that impacts how we should run unit tests.
Subprojects using the non-Godot SDK reference in their csproj files should be unit testable if we move them off of netstandard targets (because netstandard is more of a virtual compatibility target than an actual platform). For any projects using the "Godot.NET.Sdk/3.3.0" Sdk attribute I have yet to figure out how to unit test those.
As for integration testing, I currently have no idea how to begin. All my Google results so far for Godot integration testing talk about the difference between unit and integration testing then explain unit testing in detail and seem to forget entirely about integration testing after that. This issue's comments may hold some value, but no silver bullet jumps out.
@WildWeazel , how does Unity handle integration testing? Do you just avoid testing graphical routines, or is there some sort of testing harness?
All that said, this is not a huge near-term goal. It's difficult to make unit tests when we have no design by contract and all the data structures are in rapid flux. But simply executing the load or save game code and making sure it doesn't crash might be a worthwhile unit test that won't blow up if the code changes. The SAV, BIQ, and media readers might could use some unit tests as their methods, inputs, and outputs shouldn't change much if at all other than to gain new code to test.