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

Re: Ruby bindings test failures on Windows

From: Kouhei Sutou <kou_at_cozmixng.org>
Date: 2007-05-09 09:08:16 CEST

Hi,

2007/5/9, Joe Swatosh <joe.swatosh@gmail.com>:

> Okay. Your patch wouldn't pass the tests because
> assert_simple_provider() can't
> be run more than once in a test (it tries to add the file to the repository
> every time). The attached patch passes the tests. I made
> test_simple_windows_provider() into three different tests. To do this I had to
> modify the block in the third test somewhat.

I think that your patch needs to a bit works:

  * add the following code to test_windows_simple_provider[23]:
      return unless Svn::Core.respond_to?(:auth_get_windows_simple_provider)

  * rename test_windows_simple_provider[123] to more self-
    describing name.

  * test_windows_simple_provider[23] may be needless.
    The authentications are passed by
    add_simple{,_prompt}_provider not
    add_windows_simple_provider. To test
    add_windows_simple_provider, we should only use
    add_windows_simple_provider and confirm a test doesn't
    raise Svn::Error::RaNotAuthorized.

    We need to learn more about auth providers...

> I didn't want to start it before asking, but perhaps it would be a good idea to
> make the assert_simple_provider() more focused and use it more like the 3rd
> test_windows_provider test? Perhaps splitting up the other provider tests a
> bit? As I said, it's not clear to me why the various provider tests need to
> have the simple provider setup so often. Could be I just don't know enough.

OK. Could you make a patch that describes your idea?

Thanks,

--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 9 09:08:32 2007

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.