Closed AdamNorberg closed 3 years ago
Five seconds on Google: xUnit (https://github.com/xunit/xunit), NUnit (https://nunit.org/).
https://github.com/godotengine/godot-proposals/issues/432 - Godot is difficult to unit test. This issue is active as recently as a couple of weeks ago.
https://github.com/NathanWarden/godot-test-tools - for nUnit, folks are already working around this. This repository hasn't been updated for three years, but if it's close to working, maybe I can get it the rest of the way...
https://godotengine.org/qa/73382/setup-nunit-c%23-on-windows - information on getting nUnit running inside the context of Godot. We'll have some tests under Godot and some tests that work independently of it (engine-targeted), but it shouldn't be hard to set up the independent tests vs. the Godot-integrated tests, we can just do a "normal" engine setup as long as the engine code is avoiding taking dependencies on the UI and graphics code. (If it isn't, we might have some refactoring to do.)
Okay, after a bunch of research, I've found that the general C# community consensus is that while nUnit is more established, xUnit is better-designed. xUnit behaves more similarly to the tools I'm used to, certainly; they've chosen some vaguely silly attribute names (a test case is called a [Fact]
, apparently) but that's forgiveable, if silly but unambiguous names are the worst problem I can find I have no qualms.
xUnit runs each test in a separate instance of the test class; nUnit reuses the test class. From personal experience, I strongly favor the xUnit approach here. That alone is enough to make me pick xUnit for a new project and, since this project has never had unit tests before, it's a new project as far as picking a test framework is concerned!
So: I nominate xUnit.
https://github.com/fledware/GodotXUnit -- running it in Godot. (Godot asset library item: https://godotengine.org/asset-library/asset/688 )
https://xunit.net - web site https://github.com/xunit/xunit -- github project
Any other views on picking a test framework?
I am currently not well informed enough in unit test frameworks to make an informed decision. Whatever you pick seems good to me! From my meager understanding, running tests in separate instances of the test class does feel like a more robust option, so I'd be in favor of that as well, though again I am not experienced enough to make a deep comment.
So, all-in-all, I'm in favor!
One question, though: how does nUnit compare with the silly names? I'm not sure it will be a dealbreaker, but it helps me give an overview of the options. :P
godotengine/godot-proposals#432 - Godot is difficult to unit test. This issue is active as recently as a couple of weeks ago.
Oh, in relation to this, I should also note that although Godot integration is highly appreciated, the engine does not and will not make any calls to Godot. This means, in principle, that we can safely unit test the engine, although we might need to go through some trouble for unit testing the UI frontend.
as the engine code is avoiding taking dependencies on the UI and graphics code. (If it isn't, we might have some refactoring to do.)
Yep, the engine is completely detached from Godot in every way! This shouldn't be an issue indeed.
This code has no tests. Step 1 in adding tests: pick a unit test framework.