asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/gdscript/tests
History
20kdc 24181d1055
GDScript: Adjust STATIC_CALLED_ON_INSTANCE warning to not default to the native type, and to not trigger on self-calls 
Not defaulting to the native type rationale:

Defaulting to the native type is less than useful, as:

* There are very few native types that are extensible and have static methods.
* Defaulting to the native type does not account for a method being script-defined.

While the "real fix" would be to carefully track the source of the method, the get_function_signature method is already complicated enough.

This will at least ensure the resulting code should always be valid.

Not triggering on self-calls rationale:

Found in PR comment https://github.com/godotengine/godot/pull/85918#issuecomment-1935864459

```
static func example():
	pass

func example2():
	example() # self-call on static function
```

Disabling this warning on self-calls is:

* Consistent with other languages
* Important for anonymous classes (where the output code is unusable)
2024-03-01 17:14:59 +03:00
..
scripts GDScript: Adjust STATIC_CALLED_ON_INSTANCE warning to not default to the native type, and to not trigger on self-calls 2024-03-01 17:14:59 +03:00
gdscript_test_runner.cpp GDScript: Enable compression on export 2024-02-08 11:20:07 -03:00
gdscript_test_runner.h GDScript: Reintroduce binary tokenization on export 2024-02-08 11:20:05 -03:00
gdscript_test_runner_suite.h Fix running tests in template builds 2024-02-22 18:05:42 +01:00
README.md Fix various typos with codespell 2024-02-07 11:09:34 +01:00
test_completion.h Allow specifying a scene in completion tests 2024-01-08 22:38:41 +01:00
test_gdscript.cpp GDScript: Enable compression on export 2024-02-08 11:20:07 -03:00
test_gdscript.h GDScript: Reintroduce binary tokenization on export 2024-02-08 11:20:05 -03:00
test_lsp.h Add unit test runner for autocompletion 2024-01-05 17:49:51 +01:00

README.md

GDScript integration tests

The scripts/ folder contains integration tests in the form of GDScript files and output files.

See the Integration tests for GDScript documentation for information about creating and running GDScript integration tests.

GDScript Autocompletion tests

The script/completion folder contains test for the GDScript autocompletion.

Each test case consists of at least one .gd file, which contains the code, and one .cfg file, which contains expected results and configuration. Inside of the GDScript file the character ➡ represents the cursor position, at which autocompletion is invoked.

The config file contains two section:

[input] contains keys that configure the test environment. The following keys are possible:

  • cs: boolean = false: If true, the test will be skipped when running a non C# build.
  • use_single_quotes: boolean = false: Configures the corresponding editor setting for the test.
  • scene: String: Allows to specify a scene which is opened while autocompletion is performed. If this is not set the test runner will search for a .tscn file with the same basename as the GDScript file. If that isn't found either, autocompletion will behave as if no scene was opened.

[output] specifies the expected results for the test. The following key are supported:

  • include: Array: An unordered list of suggestions that should be in the result. Each entry is one dictionary with the following keys: display, insert_text, kind, location, which correspond to the suggestion struct which is used in the code. The runner only tests against specified keys, so in most cases display will suffice.
  • exclude: Array: An array of suggestions which should not be in the result. The entries take the same form as for include.
  • call_hint: String: The expected call hint returned by autocompletion.
  • forced: boolean: Whether autocompletion is expected to force opening a completion window.

Tests will only test against entries in [output] that were specified.

Writing autocompletion tests

To avoid failing edge cases a certain behavior needs to be tested multiple times. Some things that tests should account for:

  • All possible types: Test with all possible types that apply to the tested behavior. (For the last points testing against SCRIPT and CLASS should suffice. CLASS can be obtained through C#, SCRIPT through GDScript. Relying on autoloads to be of type SCRIPT is not good, since this might change in the future.)

    • BUILTIN
    • NATIVE
    • GDScripts (with class_name as well as preloaded)
    • C# (as standin for all other language bindings) (with class_name as well as preloaded)
    • Autoloads

  • Possible contexts: the completion might be placed in different places of the program. e.g:

    • initializers of class members
    • directly inside a suite
    • assignments inside a suite
    • as parameter to a call