[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: query on writing test scripts

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-02-15 18:14:43 CET

Brian W. Fitzpatrick wrote:

>
> On Feb 15, 2005, at 12:40 AM, Madan U Sreenivasan wrote:
>
>> C. Michael Pilato wrote:
>>
>>> If your test script is meant to be part of Subversion's own test
>>> suite, take a look at the svntest Python module that comes with
>>> Subversion, in particular the svntest.run_and_verify_* functions.
>>> [...] Even if your test script is *not* meant to be part of
>>> Subversion, you
>>> might consider learning from the svntest module anyway.
>>>
>> Hi Mike,
>> Yes, this is for the subversion test suite.....I did look into the
>> run_and_verify_* functions... it was useful....rather essential
>> to....;-)
>> But my question is different....it relates to the logic to be
>> used.... To give a short background,
>> subversion/tests/clients/cmdline/trans_tests.py says ...
>> <quote>
>> # These have all been fixed, but we want regression tests for them.
>> #
>> # 1. Ben encountered this:
>> # Create a greek tree, commit a keyword into one file,
>> # then commit a keyword property (i.e., turn on keywords), then
>> # try to check out head somewhere else. See seg fault.
>> <unquote>
>> I feel that it would be good to check the contents of the checked
>> out file, rather than just 'catch'ing a seg-fault.... I wanted
>> others' opinion on this....
>> Pl. let me know what you think.
>
>
> If a segfault is the error you're fixing, then I'd say checking for
> the segfault is an adequate test.

Indeed, but we don't have a portable way of detecting segfaults in the
test framework. I wish...

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 15 18:43:08 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.