Re: make testing more accessible to contributors

Tony Graham wrote:
> Stefan Seefeld <[email protected]> writes:
> 
>>When trying to confine a bug I tried to first see whether it was already
>>covered by an existing test. Unfortunately, I found the existing test
>>infrastructure a bit confusing / hard to use.
>>
>>Is there anything that could be done to make that easier ? Ideally
>>I would only need to have to check out an additional module (not two !)
>>and then run 'make check' (or similar) in it.
>>I did glance over some READMEs both in 'testsuite' as well as 'testing',
>>but couldn't quite get it to work.
> 
> 
> Are you still stuck?

Sorry, haven't had time to look at it again after your explanations.
The reason I asked originally was because I was looking for some test
case I could use to find out whether some issues I observed with my own
document were known / expected.

Meanwhile I get my answer without looking at the test suite.

I still think that the test suite is important not only to developers,
but also to users who want to know what they can expect from xmlroff.
However, for the latter it would be best if features were expressed in
terms of their own language, e.g. docbook constructs that would fail,
instead of fo (which most users only care little about).

However, I can understand that it is out of the scope for xmlroff, and
you in particular, to set up a list of such issues.
Or may be it is some combination of the existing test suite results
with the filtering done by libfo-compat.xsl...

Regards,
		Stefan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642