Re: Best practices

"Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message news:3D246FC0.EF6637A3_at_exesolutions.com...
> The potential error was in fact two fold. One that it would not handle
NULL. But
> that was an issue QA could catch is the spec said an account type was
mandatory
> and this was enforced with NOT NULL and testable. What was not testable
was that
> the bank might, and I emphasize "might" add other account types later.

I'm not entirely sure how that is different from my suggestion that QA put invalid values in the test data. though a list of valid account types ought to be testable with a check constraint. I confess i'd probably miss it on code review but spot it when one of my colleagues puts rubbish values through in sql*plus.

> It is not testable because since those account types didn't exist at the
time of
> the testing every single test passed with flying colors.

that is , as i suspect you know, one of the issues with testing. You don't just test to see does the ap work as designed you also test to see what happens when the app is used *not* as designed. my 99 hours of work a day eg was supposed to illustrate this. only consultants can record this much time <g>.

> Amazingly enough, I recieved an email from an employee there yesterday
that saw
> this thread and said she found a similar situation in some code, again,
just a
> few weeks ago. Just about any IF statement that can't handle ELSE is a
potential
> disaster waiting to happen. And the place to catch it is in code reviews
... not
> in production.

absolutely. any thoughts on my record a value for each of the 48 half hours or 24 hours in the day?

--
Niall Litchfield
Oracle DBA
Audit Commission UK