Figure out how to test the bindings.

[nical]

And write some automated tests, especially for types that are reimplemented by hand like math types.

[vurpo]

Not sure if any types need to be implemented by hand, the ones that are implemented by hand are just there so I had something to work with.

[nical]

Some types (math related stuff in particular) benefit from being able to be inlined rather than crossing the C API and dynamic library boundary every time a member is accessed. I agree that some of the other types will be better off just wrapping the C API, though.

[nical]

I added in #17 a very primitive testing infrastructure which lets you write a tests like this:

godot_test! {
    test_foo {
        // Test stuff, panic if something is wrong
    }
}

And a simple godot program in the test/project directory that calls these tests (the macro does not register them automatically so they have to be added in test/src/lib.rs.

To run the tests, do:

cd test
cargo build
cp ../target/debug/libgdnative_test.so ./project/lib
godot --path ./project

We should add a script to simplify this and figure out how to run this in the CI (it requires the godot to be installed), but it's a good start.

Now let's write some tests.

[karroffel]

Maybe this PR will be of help when running tests on a CI machine (since those usually don't have X11 etc installed)

[memoryruins]

Testing on a Windows set-up today. It builds the test library with the filename gdnative_test.dll instead of libgdnative_test.dll (on linux, it was libgdnative_test.so as expected). After a rename, the tests ran successfully :)

edit: default resource path renamed #56

[tom-leys]

One thing you could do is to add a test which checks that every class is found in ClassDB, and build all the function tables looking for methods which can't be bound.

Another idea would be to build a set of classes in ClassDB. Then subtract all classes we have already in bindings and write that out so you know what is missing from the API.

Thanks for the great work so far btw.

[karroffel]

Those are nice ideas, that would probably show a some issues with the bindings that we still didn't encounter yet. 👍

Maybe we should investigate a little more in how testing could be done, the Godot "server" build seems like a good fit for something like that, we'd just need a custom test-harness to make use of that.

[Bromeon]

Also important: document findings in https://godot-rust.github.io/book/testing/engine.html

[Bromeon]

This has been implemented long ago in CI (Godot integration tests).
I'll close it, further improvements can be tracked separately.