search

Freedom-of-Form-Foundation / anatomy3d

A CAD tool for humanoid anatomy alterations. See the anatomy3d-blender repository for more recent work.
https://freedomofform.org/1856/3d-anatomy-project-scope-phase-1-focus-on-a-limb-joint/
GNU General Public License v2.0
7 stars 5 forks source link

Pick a unit test framework #12

Closed AdamNorberg closed 3 years ago

AdamNorberg commented 3 years ago

This code has no tests. Step 1 in adding tests: pick a unit test framework.

AdamNorberg commented 3 years ago

Five seconds on Google: xUnit (https://github.com/xunit/xunit), NUnit (https://nunit.org/).

AdamNorberg commented 3 years ago

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.

AdamNorberg commented 3 years 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...

AdamNorberg commented 3 years ago

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.)

AdamNorberg commented 3 years ago

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?

Lathreas commented 3 years ago

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

Lathreas commented 3 years ago

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.