You two guys are tough to follow ;) anyway, I'm more a code person than a patch person, and I believe I am not alone, so this is why pdtest has a Lua code core. I totally see your point that tests are better to be implemented in way the external is to be used, i.e. within pd, but I think code still allows this by only being the test dataset emiter and receiver, and has the advantage to have readable code input being close to specifications and a test output log that tells you if it flies or not at a quick glance. Still, pdtest alway need to work inside a test patch adapted to the problem at hand, as what it does is only to output messages and pair them with expected messages to be received back.
2011/9/14 Mathieu Bouchard <[email protected]> > Le 2011-09-14 à 10:47:00, Hans-Christoph Steiner a écrit : > > > Signals are quite easy to test within Pd. I think it could make sense to >> keep the management of the tests in Lua, but keep the tests as Pd patches. >> That way they'll be easier for Pd people to write tests since they would >> just be patches, and you can more easily test Pd-ish things. >> > > It also makes sense to keep the management of tests in Pd, and to keep the > tests in Pd. That way, it'll be easier for Pd people to modify the test > framework to better suit tests. > > > ______________________________**______________________________** > ___________ > | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
