Project restructure for Unit Testing capabilities and easier, automated game project dependency

[sesopenko]

Is your feature request related to a problem? Please describe. As a plugin developer contributing to this repository, I shouldn't have to copy my working files to a Godotgame to test them out.

As a game developer depending on this repository, I should be able to simply declare a git submodule to add this to my project, and it'll be kept up to date, instead of copying/pasting the contents of zip files and git clones around.

This is a difficult library to work on due to the lack of unit tests confirming changes. It's also difficult to import into a project using an automated system such as git submodules because this project needs to be put in the root of the main game project.

Describe the solution you'd like A reorganization of the files to no longer be in an addons/dialogic directory, but instead have all of the plugin files right in the repo root. This would allow one to use the project as a git submodule, or even manualy clone the repo in their own game project's repo, ignore this project, and not have to worry about altering files to get it working.

This restructuring would allow for .sln and .project files for NUnit tests of the C# code, increasing resiliency of code changes through automated unit tests.

We could introduce automated github actions for builds, to produce artifacts when tags are created for release version.

Describe alternatives you've considered A shell script my artists can run to keep this plugin up to date in our project, but it doesn't solve the problem for somebody who wants to contribute to the library having to copy/paste things around as they work.

Additional context I have experience with test driven development, automated build pipelines, and have used Gut enough that I could probably hoist the initial testing frameworks up for the C# and GDScript code.

Once a build pipeline is set up via the github actions, it's possible to automatically publish released versions to the Godot Asset Library, and simply refer devs to use the asset library to get the latest version. I haven't looked into this in detail yet, but it should be scriptable.

[Jowan-Spooner]

Hi. Thanks for this idea. I do have to say that this is the first project I contribute to, thus I'm not to experienced with github and other workflows. It might very well be that the workflow you suggest is the better one, and then I would be happy about help to set it up and get it working.

You do not have to copy your changes everytime to a different projec to test them tho. You can setup a test project under res://test-project/ and it will just be ignored by git. So the only time you have to copy and delete stuff is when updating. Still you might be right that there are better ways.

I've no experience with submodules or test driven development and automated build pipelines (maybe @coppolaemilio knows more about that) but I'm sure there is always ways to improve the project structure.

[AnidemDex]

Is this related somehow to #45? Just wondering

[Jowan-Spooner]

Is this related somehow to #45? Just wondering

Nah, although both are good ideas, I think this focuses on the git management and file-system structure while #45 is about the internal project-logic.

[sesopenko]

I'll create a template project in another repository to act as a demonstration, then will ping back in here when it's ready to demo. It'll be beneficial to more than just one plugin project that way, too.

[coppolaemilio]

I wanted to create a repo to test dialogic with a series of timelines and stuff like that but not """proper""" unit testing https://github.com/Dialogic-Godot/Dialogic-Test-Project I'm not a fan of automated tests and having a complicated stack of technology to handle a project. But if there are some small changes or improvements we could make I'm up for it :)

[sesopenko]

Can somebody summarize their current workflow for making changes to this repository, and how they test their changes, for gdscript code especially, and C# code if possible? (I'll start on the template project tonight)

[AnidemDex]

Can somebody summarize their current workflow for making changes to this repository, and how they test their changes

There are not something like that. Most of PR are just things that works. If it doesn't works, or stop working on a project that was already using dialogic, is fastly reverted

[coppolaemilio]

I don't do any testing on C# because I don't use it, but with gdscript I (ideally) manually test the feature added and the other things that interact with it. We try to do QA of the entire thing before a big release and in-between since most of us are using the plugin we report everything we see. So the main branch is super unstable until it gets to the release.

[sesopenko]

with gdscript I (ideally) manually test the feature added and the other things that interact with it. We try to do QA of the entire thing before a big release and in-between since most of us are using the plugin we report everything we see. So the main branch is super unstable until it gets to the release.

Ok so automated gdscript testing would be the most helpful, initially. I'll demonstrate the following in a separate repo:

1. create a godot project for the plugin, somewhere in the repo, just used for testing purposes
2. add the GUT (godot unit test) plugin to that project,which allows for unit testing.
3. Then regression tests can be caught in an automated fashion via a CLI command and/or an automated build action in github.

After the POC is created, I can demontrate an automated test for one of the gdscript files, and then provide feedback on whether it'll be helpful to restructure the entire project for automated testing.

Typically, automated release pipelines work as thus:

• every PR runs automated tests confirming the health of the code base
• The mainline branch runs automated tests in github actions with every commit/merge
• When a tag is created, a github action automatically runs the tests, then automates the packaging of a zip and .tar.gz file for download in the releases page of the github repo
• The godot plugin is updated in the godot asset library (I've done some investigation and the godot asset lib isn't sophisticated enough for this, their update process is highly manual)

I'd like to help automate a bunch of the release management work in this project because I feel it's one of the best (if not the best) story telling systems integrated right in a game engine. This plugin can help any game developer cover a lot of ground with world building, plot development, etc, etc.

I came to this project after a few weeks of research, compiling a list of helpful tools needed for a narrative heavy game project myself and others are starting, and this plugin was identified as our most critical dependency of our project, so it'll be a win/win.

[bitbrain]

Over at the fmod-gdnative Godot addon we also have GUT tests. Here is the setup we are using: https://github.com/utopia-rise/fmod-gdnative/blob/master/.github/workflows/all_builds.yml#L361

[exelia-antonov]

Since this wasn't mentioned specifically in the previous comments, on the topic of restructuring the Git to make better submodule function, unfortunately it seems this is impossible as desired, because this is the structure the Godot Asset Library needs

What I ended up doing to allow submodule use, was using symlinks. Have the actual Godot project in a subfolder of the Git repository for my project, and then Dialogic in another subfolder synced as a submodule. Then in the /project/addons folder, adding a symlink to /dialogic/addons/dialogic. Godot can see it just fine and use it as long as the file system supports that. It's a little more cumbersome particularly on Windows, where it'd harder to make symlinks and cloning the repository in a new folder doesn't automatically rebuild them and you have to manually do it, but on macOS and Linux it will sync and rebuild the symlink from the actual Git repository

[bitbrain]

This looks actually much better than GUT tbh: https://github.com/MikeSchulze/gdUnit4

[coppolaemilio]

I will close this issue because it is too broad and some of the suggestions already made it in.