Because of this I have a keen interest in the final bill which - it is claimed - I can retrieve from the company web site, where a form to that effect is provided. The bill itself can be searched by surname of the renter (yours truly) and reservation number: mine looks like IE123456789.
Power of the NET. After dinner, I fire up my device, go to the site, fill in the required numbers, and WHAM-BAM-ALAKAZAM I am greeted by a pink box, containing a twelve line SQL error enchantement. Not being at the office, I cannot be bothered, think "Oh, well, system maintenance or sump'in" and go back to my book.
Two days and four ALAKAZAMs later, however, I am nervous and annoyed enough to make the form's problem my own. The above mentioned statement includes the code ORA-01722 error (which, for the uninitiated, is an error code of the underlying ORACLE DBMS) As it happens, its textual description is "invalid number" (I had to look it up). Being the adroit IT professional I am, I fired up the form again, entering 123456789 as the reservation number (rather the IE123456789 that is present on all the documents I have been given) and ALAKAZORK! "No document found".
Now that is still a problem (for me) but not an error, and therefore, not the topic I'm after in this post.
Here are some things I am fairly sure of
- There is no chance in hell that anybody, except the useless author of this useless form (who should be metaphorically taken to the backyard and shot, but I digress) have ever been able of making it work at the first attempt (and very few people even after the 100th).
- All the system has been built with a test-driven approach, as the extreme programming best practices dictate;
- But the reservation number is actually made up by the two letter country code (IE) and a number and these, in the database, are split between two columns (countrycode, textual, resnum, integer)
- and the aforementioned useless git has successfully run its tests against the contents of the resnum column, never - in his/her useleness - checking what the customer documents actually contain, because that would require the capability of thinking
- form field validation code is for sissies
All of which bring us to the proof of these interesting corollaries of software testing:
Corollary 1 (extreme GIGO)
"If your tests suck, your code will suck, for any number of successful tests Nt > M, Nt and M being positive arbitrary integers and for any input I to the tests"
This, coupled with the following :
Empiric finding 1
"A stupid programmer will conceive stupid tests"
(I.e. for a nuclear power generator control software he will test for correct string justification but not for correct temperature reading of the core; in case he does, he will mix up fahrenheit and centigrades).
Empiric corollary 2
"A stupid programmer will conceive thoroughly tested sucky code"
A more useful way of stating this is, do not let anybody write tests for their own software (we all go through bouts of stupidity, after all, especially when our own children are involved), or, in other words, separate development and QA.
Advice of the day: "Don't be stupid"