On 27.06.2021 19:40, Ichthyostega wrote: > > Hi Will, > Hi Kristian, > > as you've probably guessed already, I was rather busy last week with my > work > job; but this weekend I was able to continue with the test feature. > There are > still those two unclear issues, and as I explained last week, for now we > can > work around those with some additional initialisation before starting > the test. > So I've focussed primarily on rounding up the changes done thus far. All > the > parameters of this built-in test functions are now exposed to CLI, together > with proper max/min/default values and help text. Also I've refined the > timing measurement to include only the noteOn|Off and MasterAudio calls, > but not the SynthEngine::shutUp() we need to send before each test note > to clear out the effect chain. > > Am 31.05.21 um 20:12 schrieb Will Godfrey: >> When you have the new code stabilised enough can you put some info in >> dev_notes please? > I will look into that next. > Yet the next major step for me is to set up a testing infrastructure > with some kind of test runner. I've already spent some time on further > planning -- probably it's best I'll do a prototype as proposal and > starting point for further discussion (and a prototype can always > be thrown away and re-done in any ways we see fit). > > I will start that within a new and separate Git repository, because > the way we've approached the testing, a test runner does not need to > link directly against Yoshimi code; all it will need is a Yoshimi > executable to launch the low-level tests via CLI and (as second step) > a Yoshimi-LV2 plugin to launch high-level integration tests. > > IMHO, keeping the test suite cleanly separated, while using the real > executable is a bonus; we can keep the test suite separate and also be more > flexible with experimenting and evolving the test suite. Eg. we could check > the baseline WAV files into that separate Git repository as a starting > point, > and just see where this leads.
Sounds good. Another advantage is that with many WAV test files, the repository might grow to a considerable size, and it's nice not to have to carry that weight in the main repository. > Regarding the language I'm leaning towards "the most simple thing" for our > project, which IMHO is to implement it in C++ and using libSOX for > processing > the samples and detecting differences. Basically we could use Boost-test > for running the testsuite. However, while I am quite fond of Boost-test, > what we do here is rather special and I don't see any gain from pulling > in /any/ library or /testing framework/. Thus I'd rather just implement > it from scratch, it is a simple programming task after all, and we > do not need any bangs and whistles, like fancy formatted XML reports > or instrumentation and Mocks and code coverage metrics and the like. +1 -- Kristian _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
