-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Unit Testing for the engine development process #918
Comments
For the reference, see also godotengine/godot#2641 which was the original proposal about this in the main engine repo. |
@akien-mga thanks! I also thought a bit about GDScript only testing but it won't cover my use case e.g. the FBX importer testing the skin mathematics, which is what I would use it for. Ideally, Godot has C++ testing which can also be used in GDScript the header example is probably the best way to handle both sides, but doctest gets us some of the way there for 4.0, so if we want it sooner rather than later it's a good approach. |
What is the status of this proposal? Was this approved? |
This was implemented in godotengine/godot#40148, closing. |
Describe the project you are working on:
FBX Importer
Describe the problem or limitation you are having in your project:
We can't write a unit test easily which runs on our CI every commit for the C++ side of godot.
We can't write unit tests for /modules/fbx_importer etc.
We have complex code that needs simple test cases declared for it without making breaking changes.
Describe the feature/enhancement and how it helps to overcome the problem or limitation:
We can integrate a testing framework that allows for tests to be written for the engine.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
At the moment unit tests are not run when any commit is made to the engine, this needs to change, we need automated C++ unit tests for the engine which run and are completely independent of the engine.
Additionally if someone finds a bug in the engine and can fix it, they could also write a unit test to be sure it doesn't return.
Meaning when we do a release we have some regression testing and basic unit tests for core and other modules.
I propose we implement our own testing interface or use the doctest PR.
Doctest - little build time increase
doctest has a limitation which won't work in shared libraries without hacks since tests are compile-time, most frameworks have this limitation.
godotengine/godot#30743 - this has a limitation of not being able to easily test modules.
Rolling our own - not too hard to maintain but requires code which doesn't use core Godot types - minimal build time increase
We can also optionally roll our own solution, this would let us test across modules/core/whatever folder in the engine, so tests could be in modules/fbx_importer/tests for example.
The reason you would use non-godot types here would be you can't test yourself or in-engine types they could cause issues with the results or with how the tests execute.
https://gist.github.com/RevoluPowered/33e154902fa668f7ac87bcabd55d9295
This could easily be integrated into GDScript too, this is pseudo code / c++
Catch 2
Google test - too big for godot source to add
If this enhancement will not be used often, can it be worked around with a few lines of script?:
no, this would be integrated into our CI/CD pipeline for each build to ensure the same behavior.
Is there a reason why this should be core and not an add-on in the asset library?:
yes, we need to write unit tests for core/ and for modules/fbx_importer
The text was updated successfully, but these errors were encountered: