On Thu, Jul 1, 2010 at 09:47, Julian Foad <julian.f...@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
