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

Re: svn commit: r958630 - in /subversion/trunk/subversion: libsvn_ra_local/split_url.c tests/libsvn_ra_local/ra-local-test.c

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 1 Jul 2010 16:41:23 -0400

On Thu, Jul 1, 2010 at 09:47, Julian Foad <julian.foad_at_wandisco.com> wrote:
>...
> That is fine for now but, if we think about possible futures, this is
> not necessarily the way it has to be.
>
> When an API definition says (or implies) that a valid URL is required,
> this means (or implies) that an invalid URL argument leads to undefined
> behaviour.  That is, if an application passes such an argument to the
> API, it cannot expect a good result for any definition of "good", nor
> can it expect that the library will throw an assertion failure, or
> crash, or rely on any kinds of behaviour whatsoever.  We already know
> this.
>
> We define our own development and testing strategy.  We *could* decide
> that our APIs will catch certain groups of invalid inputs in a certain
> way (at least in debug builds), and we *could* decide that we will have
> tests that ensure we have remembered to catch those invalid inputs in
> that way.  That would be a valid engineering practice, and if we did
> then the test suite by definition *would* be allowed to pass "invalid"
> arguments.  (The non-URL argument would be classed as "invalid" with
> respect to the API promises that apply to regular API users, but as a
> "valid" test case within the confines of our chosen testing practices.)
>
> However, we haven't decided to do our development that way.  Therefore I
> removed the part of the test where it expected the undefined behaviour
> to be a particular behaviour.

Agreed on all parts!

Yes, one day we could define the expectation, then test for that. But
that will be another huge batch of work :-P

Cheers,
-g
Received on 2010-07-01 22:42:51 CEST

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