blocksds / sdk

Main BlocksDS SDK repository
https://blocksds.github.io/docs/
130 stars 5 forks source link

Add way to run tests in an automated way #142

Open AntonioND opened 3 months ago

AntonioND commented 3 months ago

Currently it's too hard to test everything by hand. We need some emulator that supports scripts and can be used to verify that things are still working. For example, check the PNG and LUA files here: https://github.com/AntonioND/ugba-testing/tree/e6dc2be5674815306c203c6d7342033254fd11c4/examples/graphics/special_effects

asiekierka commented 2 months ago

The best approach, in my opinion, would be to work with melonDS. I've consulted one of their devs on this a bit, and here's what I found:

There's a Lua scripting PR which is essentially done, but was abandoned due to issues with the macOS CI. Resurrecting it would make for a good first step, and also be of great use to other developers.

From there, one would need to refactor it to be independent from the Qt frontend, and develop a simple headless frontend. melonDS can be configured to not require OpenGL, and the emulation core is separate from the Qt frontend already (as there's a fairly mature alternative libretro-based frontend).

Then, one could use such a headless melonDS build to run automatic tests - even in a server/CI context, which would allow using GitHub Actions to automatically check commits for regressions. Cool!

AntonioND commented 2 months ago

If that PR can be revived, it would be ideal, yes. Even if QT is still required, it would be useful. I could run the tests locally every now and then and before tagging a release, for example.

asiekierka commented 2 months ago

I talked about it, and it absolutely can, it's just a matter of someone finding time to do it.

asiekierka commented 1 week ago

A good first step would be to introduce CI and testing for the most basic test: checking whether <nds.h> can be successfully included across all C and C++ standards versions we support.

This has recently been added by picolibc when an in-development change caused a regression by adding code to the header that was valid in C, but not in C++.

It would also provide scaffolding that could be re-used for runtime tests later.