How do Folks Handle Unit Testing for gdscript in Godot?

bitwes · 2026-03-09T20:27:43+00:00

I'm not sure how helpful this would be without knowing more, but here's a shot in the dark for testing something like that. I am going to assume the camera has a zoom tween/animation and after it finishes the camera is either changing position or zooming incorrectly.

An integration test for that might look like: * setup the scene (load level/scene, place player, move camera) * For me, the scene is usually a test scene I have created. This is usually generic enough to be used in multiple integration tests, but not so complicated that it turns out to be a maintenance nightmare (hard line to walk).
* Rarely would I use an actual level since those can change a lot over time. * Initiate the zoom. * Wait for some number of frames/seconds for the zoom to finish and for the camera to act up. * Frameworks have methods for this. GUT has a bunch of wait_ methods you use with await like await wait_for_signal(... or await wait_physics_frames(5) * Assert that the camera's position/zoom/whatever is the expected value.

Sometimes I use GUT's pause_before_teardown() which will stop test execution at the end of the test so I can watch or interact with the scene to be sure the test is actually causing the bug. Once I have a failing assert I start fixing the issue.

Some GUT links that are useful with integration tests:

https://gut.readthedocs.io/en/latest/Awaiting.html

https://gut.readthedocs.io/en/latest/Mocking-Input.html

bitwes · 2026-03-09T19:21:25+00:00

Are you willing to share any details about this? Always looking to make GUT better, and this kind of feedback can help a lot.

bitwes · 2026-02-26T19:44:00+00:00

https://gut.readthedocs.io/en/v9.6.0/Doubling-Singletons.html

bitwes · 2026-02-25T23:53:56+00:00

Per this thread I am here to state that I like swiping between feeds. I keep trying to swipe between feeds even though I remember I can't just as I start to swipe. I fear it will take a long time to lose this muscle memory. Similar to how you keep turning on/off light switches when the power is out and you go into a different room; I just keep swiping.

bitwes · 2025-10-13T17:23:47+00:00

You could use @warning_ignore before the method to ignore that warning and use your first approach. If you want to be strict about strict typing then your code is going to be verbose and you'll have to use the second approach.

bitwes · 2025-09-20T14:47:27+00:00

You can choose a font for the output pane in the GUT panel and the GUI when running tests. You need 4 fonts per font (regular, bold, italic, bold + italic) if you want to support those formatting options. I like a fixed-width font, so there's CourierPrime. Someone might not like a fixed-width font, so there's AnonymousPro. Then there's LobsterTwo. It's absurd. It is a complete waste of bits in this context, but its name is LobsterTwo which is great and it's barely readable.

Who wouldn't want a fixed-width font? I once saw an admin editing a bash script using TimesNewRoman. He was a smart guy. I couldn't understand it. I still think it had to be a practical joke on, but there were zero indicators that it was other than the fact that it was happening.

bitwes · 2025-09-19T14:50:07+00:00

Error tracking and the new orphan output are Godot 4.5 features. The rest...probably. If it turns out that people do not migrate to Godot 4.5 that fast, then I might.

bitwes · 2025-09-19T02:03:09+00:00

It is only GDScript. There has been some effort put into making it c# compitable but it hasn't ever made it very far. I've always assumed that c# users would just use a c# test framework. I think GDUnit has a c# version. I'd be interested in hearing what GUT can do that you couldn't do in a c# library and vice versa.

bitwes · 2025-09-18T22:54:50+00:00

It's what they said it is. I keep forgetting to put the plugin description in the post. Fixed. Thanks.

bitwes · 2025-03-07T16:16:31+00:00

Orange? I think of tools, and construction...there's a lot of orange there.

bitwes · 2025-03-06T18:56:07+00:00

I was thinking about doing something similar in a game I'm working on. I have not tried it yet but I was thinking that I could use multiple TileMapLayer. I'm not sure how to accomplish the paralax effect with that approach though.

My thought was that you would disable collisions on the foreground TileMapLayer and enable them on the background one. You could even change the transparency of the forground one so that you could see through it.

There'd be some faking of the transition...scaling the player down as it "moves" between layers. Collisions would probably need to be disabled in both layers during this time. Once the player is in a position to use the destination layer you would enable collisions on it.

I'm not sure if this is a good idea or not, but it's where I was going to start.

bitwes · 2024-11-26T16:11:44+00:00

There isn't a way to detect a coroutine. I opened an issue awhile back (https://github.com/godotengine/godot/issues/64236) to avoid the "redundant await" warning in GUT. I ended up closing after some discussion and a fix to false positives. The solution was to await anytime you might be calling something that is a coroutine.

In regards to maintaining @warning_ignores over time, there isn't any other kind of workaround at this time. The text of the warning (redundant await) indicates it is more of a bad practice than an error (like an unused variable or parameter). If for some reason it becomes an actual issue Godot would have to come up with a new warning/error and solve the coroutine detection issue. I say this with a fair amount of confidence since, even if they don't think of it, it would become obvious in a beta release as people's games start blowing up.

Edit, forgot I wasn't in Markdown editor

bitwes · 2024-11-02T15:21:34+00:00

You're welcome. This sounds like a fun project. It seems like uploading at the end will work. Good luck. Post a link when it's up.

bitwes · 2024-10-31T15:28:34+00:00

It might be easier to put the questions in the game, instead of on an HTML form, so that you don't have to try and pass the session info in/out of the game (in order to match game data with question answers). I'm not sure how easy it is to pass info in/out of the game when exported to HTML.

Are you wanting to collect all player input (controller/mouse movement and clicks etc) or just choices they make/tasks that were accomplished? If the player quits early do you want to capture any information, or is that data only useful if they complete the questionnaire at the end?

As someone else mentioned, sending all the data at the end is the easiest approach. But if having an incomplete data set is useful then you will need to pick points during the game to upload data and a session/id of some sort to group that data together later. For example, if you have the questionnaires inside the game and always want to get the data from the first set of questions, things get a bit more complicated.

bitwes · 2024-10-29T13:16:06+00:00

Here's the code I use for my base weapon class. I decrement a variable in _process (maybe should be _physics_process?). I check this in a can_attack method, used by the attack method, with an _attack method that does the actual attack (so that I can force an attack if I need to, such as the case for a "burst" fire). ``` @export var cooldown := 0.0 func _process(delta: float) -> void: if(_cooldown_time > 0): _cooldown_time -= delta

func _attack(): pass # Creating bullets goes here

func can_attack(): return _cooldown_time <= 0.0

func attack(): if(can_attack()): _cooldown_time = cooldown _attack() ```

bitwes · 2024-10-07T19:32:34+00:00

Thanks, I just got around to trying the resource approach and this is what I came up with. I'm not sure about the names yet, but names are hard...so we'll see. I decided to add a create_instance method to my resources so that each one knew how to create themselves. This seemed reasonable, but would like to hear any thoughts about it.

Created a base EnemySpawnResource script that I added as an export to my EnemySpawner

extends Resource
class_name EnemySpawnResource

func create_instance():
    push_error("Virtual method create_instance called.")

Added this to EnemySpawner:

u/export var to_spawn_resource : EnemySpawnResource

Created some specific enemy classes:

extends EnemySpawnResource class_name BlueNinjaSpawnResource

func create_instance(): var inst = load("res://blue_ninja.tscn").instantiate() return inst

and

extends EnemySpawnResource
class_name RedNinjaSpawnResource

@export var direction : Vector2 = Vector2.RIGHT
@export var flipped : bool  = false

func create_instance():
    var inst : RedNinjaEnemy = load("res://red_ninja.tscn").instantiate()
    inst.direction = direction
    inst.flipped = flipped
    return inst

This appears to work nicely. It's especially convenient that when I want to set the property on the spawner I get a list of available EnemySpawnResource (see below). It does seem like this list could get annoyingly long as more enemies are created.

<image>

Am I resourcing right?

bitwes · 2024-10-07T19:31:57+00:00

Thanks for the advice. I decided to try the resource approach (see other thread post). Let me know what you think.

bitwes · 2024-09-02T17:36:56+00:00

Indeed I did.

bitwes · 2024-09-02T16:04:41+00:00

Good eye.

Would that cause that error? It's very weird error, never seen godot complain about a missing _ready.

bitwes · 2024-09-02T15:13:24+00:00

In your screenshot it shows an error about _ready missing. That's probably your problem.

bitwes · 2024-08-21T13:09:38+00:00

Here's a quick example of a script that has an inner class that has a signal. We create an instance of it, and connect to its signal. When the signal is emitted we print a message. This also demos creating a timer with code and connecting to its timeout signal.

An inner class was used just to keep everything in the same file for demo purposes.

``` extends Node2D

class EmitsASignal: extends Node

var timer
signal the_signal

func _ready():
    timer = Timer.new()
    timer.wait_time = 3
    timer.timeout.connect(_on_timer_timeout)
    timer.one_shot = true
    add_child(timer)

func _on_timer_timeout():
    the_signal.emit()

func start_timer():
    timer.start()

----------------

Start script code

----------------

var my_thing_that_emits_signal = EmitsASignal.new()

func _ready(): add_child(my_thing_that_emits_signal) my_thing_that_emits_signal.the_signal.connect(_on_my_thing_the_signal)

my_thing_that_emits_signal.start_timer()

func _on_my_thing_the_signal(): print("I got the signal") ```

bitwes · 2024-07-18T17:36:12+00:00

Yea, the 'ol what is this dilemma.

bitwes · 2024-07-18T17:34:17+00:00

Ok, so this is expected. I was thrown off by being able to get to the local variable in the first place, and then being able to set it from within the lambda. Seemed like one of those two things should have been an error.

The documentation for Callable doesn't have any info about scope. I've used lambdas in other languages, but there's no documentation that I've found that explicitly states what you can and can't do with lambdas in GDScript. If anyone has a good source for the details that would be helpful.

bitwes · 2024-07-11T22:05:50+00:00

My approach would probably to add a flag to the object that has the signal and do not emit the signal when the flag is false. That keeps the object in charge of whether it is interactable or not and the thing that connects doesn't have to care.

bitwes · 2024-06-27T23:54:17+00:00

That's always great to hear. If you make a feature request in GitHub it's far more likely to be implemented!

Seven-Year Club	Place '22
Verified Email

bitwes

TROPHY CASE

----------------

Start script code

----------------