On Nov 3, 2011, at 7:48 PM, katja wrote:
On Thu, Nov 3, 2011 at 10:06 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think the test abstractions should probably be distributed as a regular library, and included in Pd-extended.
That is easier to manage indeed. So you would have externals/unittests/ with abstractions, and dirs like externals/creb/unittests/ with the actual tests, only working when the unittest lib is loaded. With the unit tests being dependent on a unittests lib, there should be a readme in each lib's unittests/ subdir about that. Additional unit test abstractions could be developed, for example to test objects with symbol output messages. But wait, does it all make sense.... The unit tests are in SVN, but not included in the build packages. Why have externals/unittest/ lib then? Or is it your intention to include unit tests in the distributed builds as well?
I think the library of abstractions should be called something other than 'unittests', more like 'testbed', 'testframework', 'testtools', 'testy', or whatever.
The idea of the library structure is to have everything that the library needs in the library's folder. So for example the Makefile is included there, and works as a standalone Makefile, or with Pd-extended. If someone distributes a library, it shouldn't need things outside of its folder to work. Obviously, it would need Pd somewhere, and for the tests, it would need the testing framework.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman