Re: svn commit: rev 3311 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_client trunk/subversion/tests/clients/cmdline trunk/subversion/tests

you (Brane) wrote:

> No, I think it's better to keep it the way it is now -- have separate tests to
> check platform-specific functionality, so that test results remain comparable

the patch i sent last night "keeps it the way it is now" for the schedule.py
tests, i.e. succeeds on non-posix platforms; however for the import tests only
the executable-related parts are posix-specific.

i can very easily convert the import test back to a "succeed on non-posix
platforms" test, but perhaps i should wait until i hear a consensus among
those who have expressed an opinion (you and Mike, so far).

> between platforms. Come to think of it, I might be persuaded to add a mechanism
> to explicitly skip tests that aren't relevant on a particular platform, similar
> to the XFAIL thing; then the fact that a test is platform-specific would be
> evident in the test list, and there'd be no "if posix"-like conditions in the
> test code itself.

i've been wondering about something...

in the python test code, i used the conditional:
  if (os.name == 'posix')

to correspond with, in the C code:
  #if DEFINED(APR_HAS_USER) && !DEFINED(SVN_WIN32)

these are not the same thing, they just happen to be the same for the
OSes we're currently building on.

maybe it's not a big deal since the set of OSes we're likely to
run on is fairly well-defined... but it still seems kinda hacky so i
thought i'd bring it up before we build the notion of platform-
specificity into the test framework any further. might we ever
need to test a feature which is #ifdef'd on something that doesn't
map nicely to platform?

-brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 19:35:45 2002