Dariusz,
There is an extensive PCP QA infrastructure included in the PCP source
distribution (it is below the top-level qa directory).
Rather than writing more unit tests in Python, I would recommend using a subset
of the existing QA tests ...
kenj@bozo:~/src/pcp/qa$ cloc .
4233 text files.
3891 unique files.
2713 files ignored.
http://cloc.sourceforge.net v 1.60 T=19.32 s (78.1 files/s, 13378.6 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
XML 32 125 25 101264
Bourne Shell 1139 14451 15459 76548
C 205 4749 2444 33380
Python 22 581 485 2194
C++ 10 463 113 1743
make 60 541 210 1721
Perl 11 128 84 672
Bourne Again Shell 3 62 74 422
ASP.Net 8 19 0 207
IDL 10 0 0 140
C/C++ Header 7 10 32 70
NAnt scripts 1 1 0 8
--------------------------------------------------------------------------------
SUM: 1508 21130 18926 218369
within this arsenal of tests, there is a "sanity" group that might fit the bill.
I am unfamiliar with autopkgtests, could you please describe:
- the goals of autopkgtests (specifically what level of testing confidence is
aimed for)
- the environment it runs in (post build, with all PCP packages installed?)
- the way it is invoked and the results it must pass back
I'll bet a thin wrapper between the autopkgtests test harness and the existing
PCP QA infrastructure will more than match the requirements and keep the test
maintenance effort with the upstream PCP development community.
Cheers, Ken.
