Re: [PD] pdtest - pd functional testing external
I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create maybe a problem linking with liblua... I will look more closely at the build steps for linux when I get some time... About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc I believe abstractions could be tested too, pdtest main limitation now is to only output and understand lists, symbols and floats but no signals. As a matter of fact, I don't see clearly how signals could be tested. L-P ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Sorry to interrupt, but just for curiosity's sake, what do you guys mean by testing? Pierre 2011/9/14 Louis-Philippe defa...@spiralix.org I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create maybe a problem linking with liblua... I will look more closely at the build steps for linux when I get some time... About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc I believe abstractions could be tested too, pdtest main limitation now is to only output and understand lists, symbols and floats but no signals. As a matter of fact, I don't see clearly how signals could be tested. L-P ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
On Wed, 2011-09-14 at 08:13 -0400, Louis-Philippe wrote: I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create maybe a problem linking with liblua... I will look more closely at the build steps for linux when I get some time... About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc I believe abstractions could be tested too, pdtest main limitation now is to only output and understand lists, symbols and floats but no signals. As a matter of fact, I don't see clearly how signals could be tested. 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. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
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 ma...@artengine.ca 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Le 2011-09-14 à 12:06:00, Louis-Philippe a écrit : You two guys are tough to follow ;) Quoi, est-ce qu'on est pas assez unanimes ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Non, pas vraiment. Mais bon, c'est ça une discussion... Quoi, est-ce qu'on est pas assez unanimes ? anyway, I'll be really happy to have other options when the need arises to test in a different paradigm, but for now I will continue to improve pdtest as it's the working solution I already have, and honestly I don't completely get how you want achieve PureUnity... I'm certainly missing some concepts and experience with pd... it will be fun to understand more as the PureUnity project goes forward. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Yeah, its worthwhile to implement it the way that is useful for you. But I think you'll find that if you implement the tests as patches, and then have the whole loading, running, and comparing framework in Lua, it'll be easier to do. As for testing signals in lua space, one way would be to have the test program just write blocks of samples and then read them back, then compare them. That's what pd is doing in DSP. .hc On Wed, 2011-09-14 at 12:06 -0400, Louis-Philippe wrote: 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 ma...@artengine.ca 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pdtest - pd functional testing external
Hi pd peoples, I looked around the pd ecosystem and didn't find much in terms of testing facilities (please correct me if I'm wrong) and so I made an external with special functional testing purposes. Test suites are written in the very simple and easy to learn Lua programming language, a test case resemble: Suite(Example suite).case(Foobar).test(FOO).should:equal(BAR) where the pdtest external will outputs symbol FOO and test will pass if it receives back symbol BAR documentation and source code can be found: https://github.com/lp/pdtest#readme I would appreciate feedback on the usability of its design. It work perfect for the external I need to test but I may not grasp what the collective need for testing is, if one exist at all in the pd world anyway. regards, Louis-Philippe ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Ahoy, I'm curious why you didn't use(*) pdlua and write your whole external in Lua? Admittedly, there probably are still some bugs relating to require(), for which fixes would be welcome - last time I checked setting the paths for the Lua interpreter was rather a nightmare with different platforms (even different distros) having different locations.. On 13/09/11 14:49, Louis-Philippe wrote: documentation and source code can be found: https://github.com/lp/pdtest#readme Claude (*) instead of borrowing GPL code and licensing as MIT-style ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
I looked early at this possibility but chose to implement it in C, for flexibility purposes as C is the raw pd programming api. But still, I took inspiration from the pdlua code where applicable and I actually wrote lots of the external in pure Lua, but instead of packaging it as external lua source files I embedded it within my C code as strings. I might be wrong, but I don't think pdtest will have problem with Lua paths... I compile and link Lua inside pdtest and then the Lua test suite files are loaded looking at pd's paths... so no need for Lua's paths at all. L-P ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
On Tue, 13 Sep 2011, Louis-Philippe wrote: I looked around the pd ecosystem and didn't find much in terms of testing facilities (please correct me if I'm wrong) and so I made an external with special functional testing purposes. Test suites are written in the very simple and easy to learn Lua programming language, a test case resemble: Suite(Example suite).case(Foobar).test(FOO).should:equal(BAR) I would appreciate feedback on the usability of its design. It work perfect for the external I need to test but I may not grasp what the collective need for testing is, if one exist at all in the pd world anyway. regarde aussi #expr-test.pd et is.pd dans GridFlow. http://gridflow.ca/ J'avais aussi commencé un projet du nom de PureUnity, un système de tests hyper-abstrait... ça fait longtemps. Ces deux choses sont censées se rejoindre un jour, quand j'y mettrai le temps. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Salut Mathieu, the concept behind #expr-test.pd looks nice... is this PureUnity? I hadn't seen it before... but anyway I think PureUnity and pdtest are sufficiently different to both exist for their own purposes, as PureUnity seems to compose tests in pd and pdtest does so in code with Lua. thanks for the cue! L-P 2011/9/13 Mathieu Bouchard ma...@artengine.ca On Tue, 13 Sep 2011, Louis-Philippe wrote: I looked around the pd ecosystem and didn't find much in terms of testing facilities (please correct me if I'm wrong) and so I made an external with special functional testing purposes. Test suites are written in the very simple and easy to learn Lua programming language, a test case resemble: Suite(Example suite).case(Foobar).test(**FOO).should:equal(BAR) I would appreciate feedback on the usability of its design. It work perfect for the external I need to test but I may not grasp what the collective need for testing is, if one exist at all in the pd world anyway. regarde aussi #expr-test.pd et is.pd dans GridFlow. http://gridflow.ca/ J'avais aussi commencé un projet du nom de PureUnity, un système de tests hyper-abstrait... ça fait longtemps. Ces deux choses sont censées se rejoindre un jour, quand j'y mettrai le temps. __**__** ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
On Tue, 13 Sep 2011, Louis-Philippe wrote: the concept behind #expr-test.pd looks nice... is this PureUnity? No it's not. What I'm saying is that PureUnity is something else, and that I'd like to expand tests like #expr-test.pd and PureUnity until I can merge the two projects. PureUnity is a set of abstractions that has much higher-level stuff in it, that resembles C++ overloading and template specialisation and such, by putting $1 in class names, etc. But I didn't put the project to real use. I hadn't seen it before... but anyway I think PureUnity and pdtest are sufficiently different to both exist for their own purposes, as PureUnity seems to compose tests in pd and pdtest does so in code with Lua. The idea behind the way I do it, is that PureData's tests deserve to be done PureData and it deserves to be comfortable to write and read. There is no need to use a separate language. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
what do you mean by: and it deserves to be comfortable to write and read. ?? what confort are you talking about? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
On Tue, 13 Sep 2011, Louis-Philippe wrote: what do you mean by: and it deserves to be comfortable to write and read. ?? what confort are you talking about? By opposition to trying to make pd unit tests without using at least one supporting abstraction, because then it becomes redundantly repetitive and boringly boring, doing a lot of patching for no good reason. But for testing lots of classes, higher-level redundancy appears, so more abstractions become desirable... writing tests is a lot like writing the applications that they test. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Any working test suite is a good thing. Its good to have options out there since people like working in different ways. I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc On Tue, 2011-09-13 at 09:49 -0400, Louis-Philippe wrote: Hi pd peoples, I looked around the pd ecosystem and didn't find much in terms of testing facilities (please correct me if I'm wrong) and so I made an external with special functional testing purposes. Test suites are written in the very simple and easy to learn Lua programming language, a test case resemble: Suite(Example suite).case(Foobar).test(FOO).should:equal(BAR) where the pdtest external will outputs symbol FOO and test will pass if it receives back symbol BAR documentation and source code can be found: https://github.com/lp/pdtest#readme I would appreciate feedback on the usability of its design. It work perfect for the external I need to test but I may not grasp what the collective need for testing is, if one exist at all in the pd world anyway. regards, Louis-Philippe ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
