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