~ubuntu-branches/ubuntu/natty/pd-zexy/natty

« back to all changes in this revision

Viewing changes to tests/README.txt

  • Committer: Bazaar Package Importer
  • Author(s): Jonas Smedegaard, IOhannes m zmölnig, Jonas Smedegaard
  • Date: 2010-08-20 12:17:41 UTC
  • mfrom: (2.1.2 sid)
  • Revision ID: james.westby@ubuntu.com-20100820121741-4kxozn8b9rhee9fr
Tags: 2.2.3-1
* New upstream version

[ IOhannes m zmölnig ]
* Adopt package, on behalf of Multimedia Team.
  Closes: #546964
* Simply debian/rules with CDBS, and don't unconditionally strip
  binaries.
  Closes: #437763
* Install into /usr/lib/pd/extra/zexy/. Document usage in REAME.Debian
  and warn about change in NEWS.
* git'ify package. Add Vcs-* stanzas to control file.
* Use dpkg source format 3.0 (quilt). Drop build-dependency on quilt.

[ Jonas Smedegaard ]
* Enable CDBS copyright-check routine.
* Add copyright and licensing header to debian/rules.
* Add myself as uploader.
* Rewrite debian/copyright using rev. 135 of draft DEP5 format.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
regression test framework
 
2
=========================
 
3
 
 
4
this is a simple framework for regression tests for pd-objects
 
5
 
 
6
HOW TESTS WORK:
 
7
---------------
 
8
each test is a patch with one (1) inlet and one (1) outlet.
 
9
a bang is sent to the inlet to start the test.
 
10
the test has to send "1" to the outlet if the test succeeded.
 
11
any other result will be considered a failure of the test.
 
12
the test MUST return a result, else it will halt the entire
 
13
testrun. (this is needed to allow objects that do not return 
 
14
in zero-time (signal-objects or other timed objects) to be
 
15
tested with this framework too)
 
16
 
 
17
example tests of [==]:
 
18
 
 
19
GOOD test:
 
20
 [inlet]
 
21
 |
 
22
 [10 10(
 
23
 |
 
24
 [==]
 
25
 |
 
26
 [outlet]
 
27
 
 
28
BAD test (will hang forever):
 
29
 [inlet]
 
30
 |
 
31
 [10 10.1(
 
32
 |
 
33
 [==]
 
34
 |
 
35
 [select 0]
 
36
 |
 
37
 [1(
 
38
 |
 
39
 [outlet]
 
40
 
 
41
 
 
42
HOW THE FRAMEWORK WORKS
 
43
-----------------------
 
44
all .pd-files in one-level-subdirectories are considered tests.
 
45
e.g. ./subdir/patch1.pd is tested, while ./patch2.pd and 
 
46
./sub/dir/patch3.pd are not taken into account
 
47
this is important if you need abstractions for your test
 
48
 
 
49
at the beginning of the testrun a file "runtests.txt" is generated
 
50
which contains all test-patches, one per line and each line
 
51
terminated by semicolon.
 
52
then pd is started and "runtests.txt" is read (via [textfile]).
 
53
for each line in the file, an object is created, a bang is
 
54
sent to the object and the result is received and compared with "1".
 
55
a result-message is printed.
 
56
when all the tests have been run, a summary of how many tests have
 
57
been run (and how many tests have been run successfully), and pd quits.
 
58
printout is first done into a logfile "runtests.log".
 
59
this logfile is printed to the stdout after pd quit.
 
60
 
 
61
 
 
62
CAVEATS
 
63
=======
 
64
 pd-0.40 has problems creating an path-prefixed abstraction when a
 
65
 library of the same name is already loaded.
 
66
 e.g. if the library "zexy" is loaded, then the abstraction ./path/zexy.pd
 
67
 CANNOT be instantiated as object [./path/zexy];
 
68
 this seems to be fixed in newer versions of pd
 
69
 
 
70
 
 
71
 
 
72
 
 
73
 
 
74