Tests pass despite GD.PrintErr(...) or GD.PushError(...)

[bjkarasek]

In documentation (https://mikeschulze.github.io/gdUnit4/testing/assert-error/) it seems that assert-error is not supported in C#. Does that mean there is no way to make tests fail when you print GD.PrintErr or GD.PushErr? Is there a workaround where I can "log" something that will make the tests fail?

[MikeSchulze]

Correct the c# API do not have a monitor to scan for Godot error logs.
Using the logging of an error to force a task to fail is very uncommon in C#.
You should use exception or return error codes to enforce error handling in your code.

[MikeSchulze]

Thanks for providing this information, i will take a look tomorrow on it.

[MikeSchulze]

Exceptions thrown in the Godot main thread are caught by Godot itself regarding the Godot exception handling.

 catch (Exception ex)
      {
        ExceptionUtils.LogException(ex);
        *ret = new godot_variant();
        return godot_bool.False;
      }

But you can still track exceptions when you test your components that throw an exception.

Can you please describe your use case in more detail, what you want to test.

[bjkarasek]

Exceptions thrown in the Godot main thread are caught by Godot itself regarding the Godot exception handling.

But you can still track exceptions when you test your components that throw an exception.

Can you please describe your use case in more detail, what you want to test.

I want to be able to implement an integration test where I create a gameplay instance, run some logic on it and then maybe do some asserts. This works fine.

But additionally if in gameplay there is some unexpected issue (in my case there was a desync between host and client as I test a multiplayer game with deterministic simulation) I want to be able to log an error or raise en exception that will fail the tests.

I tried catching the exception and somehow failing the tests this way but failed to do so, though maybe I didn't do it correctly.

[MikeSchulze]

Ok, if I understand you correctly, you have a running game server-client interaction and you have an error handling you want to test.

The best way is to test the components as unit and not as an integration test.
So I would recommend testing the error handling directly.
For example, if there is an error in the client that fails due to a server communication, the test should be structured as follows.
You should use a mocked server so that it corresponds to the error image, call the client in the test and check whether the error is handled.

[bjkarasek]

Ok, if I understand you correctly, you have a running game server-client interaction and you have an error handling you want to test.

The best way is to test the components as unit and not as an integration test. So I would recommend testing the error handling directly. For example, if there is an error in the client that fails due to a server communication, the test should be structured as follows. You should use a mocked server so that it corresponds to the error image, call the client in the test and check whether the error is handled.

Instead of testing error handling I simply want the integration test to fail if something unexpected happens. So another example would be let's say a test where I spawn a building on a map (a strategy game) and the building is actually spawned properly and it exists so asserts pass, but there is some null reference exception thrown because some internal building logic failed after it was properly spawned.

I guess it's reasonable that a test should verify a single unit, but I hoped to do maybe an unusual approach where instead of testing a single thing, I can run a complicated integration test and other than asserting some conditions, simply verify that there were no errors and no exceptions were thrown.