re beginner

[John Machin]

On 5/06/2006 10:30 PM, Bruno Desthuilliers wrote:
> John Machin a écrit :
>> On 5/06/2006 10:38 AM, Bruno Desthuilliers wrote:
>>
>>> SuperHik a écrit :
>>>
>>>> hi all,
>>>>
> (snip)
> 
>>>> I have an old(er) script with the following task - takes a string I 
>>>> copy-pasted and wich always has the same format:
>>>>
> (snip)
>  >>>
>>> def to_dict(items):
>>>     items = items.replace('\t', '\n').split('\n')
>>
>>
>> In case there are leading/trailing spaces on the keys:
> 
> There aren't. Test passes.
> 
> (snip)
> 
>> Fantastic -- at least for the OP's carefully copied-and-pasted input.
> 
> That was the spec, and my code passes the test.
> 
>> Meanwhile back in the real world,
> 
> The "real world" is mostly defined by customer's test set (is that the 
> correct translation for "jeu d'essai" ?). Code passes the test. period.

"Jeu d'essai" could be construed as "toss a coin" -- yup, that fits some 
user test sets I've seen.

In the real world, you are lucky to get a test set that covers all the 
user-expected "good" cases. They have to be driven with whips to think 
about the "bad" cases. Never come across a problem caused by "FOO " != 
"FOO"? You *have* lead a charmed life, so far.

> 
>> there might be problems with multiple tabs used for 'prettiness' 
>> instead of 1 tab, non-integer values, etc etc.
> 
> Which means that the spec and the customer's test set is wrong. Not my 
> responsability.

That's what you think. The users, the pointy-haired boss, and the evil 
HR director may have other ideas :-)

> Any way, I refuse to change anything in the parsing 
> algorithm before having another test set.
> 
>> In that case a loop approach that validated as it went and was able to 
>> report the position and contents of any invalid input might be better.
> 
> One doesn't know what *will* be better without actual facts. You can be 
> right (and, from my experience, you probably are !-), *but* you can be 
> wrong as well. Until you have a correct spec and test data set on which 
> the code fails, writing any other code is a waste of time. Better to 
> work on other parts of the system, and come back on this if and when the 
> need arise.

Unfortunately one is likely to be told in a Sunday 03:00 phone call that 
the "test data set on which the code fails" is somewhere in the 
production database :-(

Cheers,
John