Am 17.05.21 um 13:16 schrieb Will Godfrey:
However, I'd still especially like to see the testing work from Hermann, ...
Hi Yoshimi-developers, currently I'm about to find out about ways to hook into Yoshimi for testing. I'd appreciate any further hints, recommendations or proposals. As we've discussed, the first thing I'd like to concentrate on is to allow for automated acceptance tests on the engine level. As you probably know, usually the testing effort today is organised into a "test pryramid", and we strive to do as much tests automated on a rather low level, since testing becomes more complicated, brittle and context dependent on higher levels of integration. Thus I'd prefer to run those engine level tests without any connection to any audio or midi system. Why? because I'd like to allow running such tests in a docker container, possibly even within some cloud service (like AWS), because this is an convenient and cheap way to ensure a comparable and reproducible execution environment over an extended period of time. Of course as a standard routine, it will always be possible to run the tests just on the local machine for development. It is important for such tests to be very easy to start, but also flexible in the setup. From a little bit of looking around and some experimentation I get the impression this is not possible right now, since Yoshimi attempts to auto-connect to ALSA. However, when I install and start yoshimi in a docker container with debian, it picks the "no_audio" backend, but segfaults then (don't bother, I'll find out what is going on there soon...) Questions: - is there some flag or option to start yoshimi with this "no_audio" and "no_midi" backend right away? Maybe we'd have to create such an option? - is it possible to launch yoshimi and immediately execute a CLI script? Ideally yoshimi should remain in CLI mode afterwards, unless the script ends with an "exit" command, in which case yoshimi should exit without much further ado. Currently I'd prefer to build some dedicated test commands into the CLI. But obviously, having a dedicated commandline argument to launch a test would be another option. A third (less preferrable IMHO) option would be to build a dedicated test executable, which links against yoshimi code. Of course, tests would always start yoshimi with a state file, in order to get a controlled environment. As said, I am in the brainstorming phase and happy to pick up any other proposed approach that is viable -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
