DevBlog #9 - automated testing

TLDR

• automated tests to be sure I'm not breaking anything
• cleaned the code by deleting 23,000 lines of unused code
• worked on several cutscenes

I am working again on God is a Cube. I am aware that last years I only worked a few days at a time on the game, and that it was mostly because everything is a mess.

So I am documenting everything, as I reinstall all software on my new computer (such as Unity), to make the whole process easier. I struggled at some points, then realized that I just needed to read again all previous devblog entries. With hindsight, some of this stuff is crazy, but at least, I can build on the effort I put in the past to make things better.

MonoDevelop

I wanted to use Visual Studio, but I still don't find a way to connect the debugger. So I will have to use MonoDevelop, at least for debugging.

I want to use the dark mode for MonoDevelop, but MonoDevelop has custom themes.
Tools > Options > Text Editor > Syntax Highlighting

I realize I did not make a save of the MonoDevelop dark theme I created last year. A mistake. But I can get it from my previous computer, if I find the directory with all themes.

It looks like MonoDevelop integrated themes do not appear on Windows file system (I'm looking for their names, but I find nothing). So I create a random style with an easily findable name, and I use Everything to find its directory. Here it is: C:\Users\me\AppData\Roaming\MonoDevelop-Unity-2.8\HighlightingSchemes.

Back on the old computer, the directory gives me my custom theme. I put the theme on the new computer on the correct MonoDevelop folder, and it does not appear. The trick is to restart MonoDevelop to see the theme available. This time I save a copy of the theme in the repo.

Testing framework

I always missed a testing framework on this game. The purpose of a testing framework is to automate tests such as checking the result of a part of the code. I also wanted to have an "ingame" testing framework, to simulate navigation in the game to validate whole scenarios, such as launching a new game and completing a first level. Basically, I want to test automatically what I had to test by hand everytime I made some big changes.

To have a testing framework, I intend to use a pure C# test project (NUnit) by referencing code or dll, but the hard part is the ingame testing framework, to do end-to-end tests (or interface tests). There is a testing framework for Unity 2019, but I am using Unity v4 from 2012 (13 years ago). I am using a version of Unity so old that even ChatGPT is making fun of me ("MonoDevelop and Unity 4, that is old school! smiley"). I read somewhere that one day, the internet as we know it will disappear, and AI such as ChatGPT will be the only way to have knowledge from this era. When looking for info about Unity 2012, it sure feels like that: it's almost impossible to find answer on such an old version of Unity, when there have been 13 more years of active Unity versions.

I gave myself a few hours to create a crude NUnit-like ingame testing framework, and it's working quite well. The most complicated part was to use coroutines the right way to simulate click on buttons and wait for the result. At least, ChatGPT is useful to understand Coroutines, which are a Unity way to execute code outside the main thread. Later in C# history, they invented Tasks and async / await (or rather, implemented from the F# language), and it was so good that all modern languages implemented it too.
Sadly, Unity 4 (2012) is using C# 3.5, which is in fact C# 3.0 from 2007 with a few addition. C# 3.5 only have coroutines (no async / await that will come with C# 5 from 2012), and those coroutines are much simpler. It was really a good thing back in the day, but when developing this crude testing framework, I am blocked by the same limitations C# devs got in this era.
Hopefully, we are now in 2025, and "coming from the future", I know what a modern testing framework needs, so I can implement it rather easily with coroutines dating from 2005 or 2007.

There were some unbelievable problems, such as Mono crashing if I try to paste an emoji. Unicode syntax works (\u2714 for a check mark ✔), but only for basic smileys in Basic Multilingual Plane, and seemingly only in black and white. So no emoji.

C# 3.5 cannot make the difference between Action (for a void method) and Func (for , so it needs 2 different methods.

I don't implement a lot of basics, such as attributes or auto detection of test methods, as I will be fine with a simple hard-coded list of all test methods.

The Menu Item "Run Tests", that can start Unity game if needed:

public static class TestLauncher
{

[MenuItem("Tests/Run Tests")]
public static void RunTest()

EditorPrefs.SetBool("TestExecution", true);
if (EditorApplication.isPlaying == false)
{
EditorApplication.isPlaying = true;

else

Testing_Data.run();

}
}


The testing data class, using EditorPrefs to communicate with the editor:

public static class Testing_Data
{
public static bool executing = false;

public static void run()
{
Testing_Data.executing = UnityEditor.EditorPrefs.GetBool("TestExecution", false);
UnityEditor.EditorPrefs.DeleteKey("TestExecution");
Debug.Log ("Testing.executing: " + Testing_Data.executing);
Main_Planes.self.StartCoroutine(Testing_Environment.run());
}
}


The hardcoded list of all tests (just a few of them for now):

public static IEnumerator run()

if (Testing_Data.executing == false)
{
return false;


while(Game_Mode.gui_current == null)
{
yield return new WaitForSeconds(0.1f);
}

Test_Credits test_credits = new Test_Credits();
yield return act2(test_credits.button_credits_is_present);
yield return act3(test_credits.button_credits_call_gui_credits);
test_credits.end();
}


How to get some info about the tests, such as the name of their method:

public class Action_Info
{
public string name { get; set; }
public Func func_enumerator { get; set; }
}

public static Coroutine act2(Action action)
{
Action_Info action_info = new Action_Info()
{
name = action.Method.DeclaringType.Name + "." + action.Method.Name,
func_enumerator = () => ActionAsEnumerator(action)
};
return act(action_info);
}

private static IEnumerator ActionAsEnumerator(Action action)
{
action();
yield return null;
}

public static Coroutine act3(Func func_enumerator)
{
Action_Info action_info = new Action_Info()
{
name = func_enumerator.Method.DeclaringType.Name + "." + func_enumerator.Method.Name,
func_enumerator = func_enumerator
};
return act(action_info);
}

public static Coroutine act(Action_Info action_info)
{
return Main_Planes.self.StartCoroutine(SafeCoroutine(action_info));
}


How to iterate on IEnumerator methods, to run them during the game execution, and detect a crash or a successful completion:

public static IEnumerator SafeCoroutine(Action_Info action_info)
{
IEnumerator enumerator;

try
{
enumerator = action_info.func_enumerator();
}
catch (Exception ex)
{
Debug.LogError("BUG Test creation " + action_info.name + "\n" + ex.Message);
yield break;
}

while (true)
{
object current;
try
{
if (!enumerator.MoveNext())
{
Debug.Log("OK Test " + action_info.name);
break;
}

current = enumerator.Current;
}
catch (Exception ex)
{
Debug.LogError("BUG Test " + action_info.name + "\n" + ex.Message);
yield break;
}

yield return current;
}
}


The tests themselves:

public class Test_Credits : Testing_Environment
{
public void button_credits_is_present()
{
var button = get_button("Credits");
Assert.IsNotNull(button, "button Credits");
}

public IEnumerator button_credits_call_gui_credits()
{
var button = get_button("Credits");
button.simulate_click();

yield return new WaitForSeconds(0.5f);

var window = get_window_bordered();
var label = window.get_all_children().First ();
Assert.AreEqual("Credits", label.text);
}

public void end()
{
((Credit_GUI)Game_Mode.gui_current).action_click_close(null);
}
}


That's just a few tests (from the main title, open the credits window and close it), but just being able to check that a window is displayed properly is already a game changer. It makes the fear disappear. The fear to have broken something.

Now, I intend to make the software more resilient by adding basic tests for all main parts of the game. This way, I will be able to easily edit the code of the game with no fear to break something elsewhere.

Visual Studio 2022

I will have to rely on Mono for live debugging, as I can't connect Visual Studio 2022 to the Unity 2012 debugger. This is a 10 years gap between the two software, and I don't think it can work.
Hopefully, I can still use Visual Studio 2022 for refactoring, such as extracting classes, adding missing using and such. Having to switch between MonoDevelop from 2012 and Visual Studio 2022 shows what 10 years can do to improve software.
When compiling, however, the first bad surprise is to discover that Visual Studio 2022 detects compiling bugs that MonoDevelop cannot see. And I don't know if the game relies on the bugs to work.

I will surely have to add a lot of tests in the game before confidently change some parts in the heart of the code.

Code deletion

To get some stats about the code, I am using Cloc, and I am checking the results with TreeSize Free with a filter "end with .cs".
The total codebase of the project is around 300k lines of C# (including 40k blank lines and 55k lines of comment), but I have to exclude third party librairies, hopefully in separated folders (127k for sqlitekit, 8k for a color quantizer, 4k for scripts).

So I have written more than 160k lines of code for God is a Cube.
I almost never deleted code from the project, since the beginning. Sometimes I created new systems and stoped using previous systems. There is still code from the first prototype, and a lot of code to generate animations used to create gifs. A lot of those code do not work properly anymore.

It becomes evident I need to remove unused code, so I took the radical option to remove all code that is no longer connected to the current game.

Working with Visual Studio 2022, each class and method display how many occurrences they have. It helps a lot to find unused code.
So far, I removed around 23k lines of code and deleted 56 C# files.

The cutscenes

I did the final cutscenes "gold" and "dark". I am still working on the "gold and dark" cutscene, for people who finish the game 100% (all gold and all dark solutions). I want it to be a lot more complex than other custscenes, as it is the final one.