anon14980890 arthuro555 hstenstrom : I would join any of you if you want to brainstorm how to make unit tests happen.
Let’s use our heads and use this thread as a starting point for a mini-brainstorm.
Provided that beginners won’t look at them, can we think of a “under-the-hood” approach, first? And, then, eventually, expose it to beginners alike via friendly interface and buttons, second.
This is because, the goal of the brainstorming is: make unit tests happen, make them work correctly, first. If, and only if, they function, GDevelop could begin finding a way to fit them into the editor interface in a friendly manner, but this is secondary to make unit tests work.
So, TL;DR:
What would you do if you had to implement your own framework for unit tests today?
And, from there, we can make a framework that works for everybody.
Another idea meanwhile: if looking at it from a practical standpoint is too complicated right now, how about taking a step back and looking at the typical workflow used in GDevelop and see where testing would fit more easily?
I took way too much space.
Your turn!
PS: I had a third idea, very simple: search this “test framework game events” on the internet → I landed on another popular game engine’s page about unit test frameworks. Maybe we can take inspiration from existing solutions?
I’ll shut up now, hehe. sorry, another idea is to log events to a “stack” and the test becomes: checking the stack for the exact sequence of steps, the same way a parser reads lexical tokens:
- an event fires and pushes a message (string, or enum, etc.) to a “log stack”
- as long as new messages pushed to the “log stack” correspond to what is expected, expected given the current state of the stack, the test keeps running and messages keep getting pushed on the stack
- when this system recognizes a sequence of messages at the top of the stack, it consumes the sequence of “log stack” events, replacing it with a single message for the recognized sequence (might be done more than once if now the top of the stack is recognized as yet another sequence)
- the test fails as soon as an unexpected event log is found at the top of the “log stack”
- the test passes as soon as the stack is emptied and no fails occurred
This was inspired by reading an article titled “logging is everything”.