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

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 matju@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

what do you mean by:

and it deserves to be comfortable to write and read.

??

what confort are you talking about?

Sorry to interrupt, but just for curiosity's sake, what do you guys mean by testing?

Pierre

2011/9/14 Louis-Philippe default@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

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

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

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 matju@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