You two guys are tough to follow ;)<div>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.</div><div>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. </div>
<div>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.<br><br><div class="gmail_quote">
2011/9/14 Mathieu Bouchard <span dir="ltr"><<a href="mailto:matju@artengine.ca">matju@artengine.ca</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Le 2011-09-14 à 10:47:00, Hans-Christoph Steiner a écrit :<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<div><div></div><div class="h5"><br>
<br>
______________________________<u></u>______________________________<u></u>___________<br>
| Mathieu Bouchard ---- tél: <a href="tel:%2B1.514.383.3801" value="+15143833801" target="_blank">+1.514.383.3801</a> ---- Villeray, Montréal, QC<br>
</div></div></blockquote></div><br></div>