Unit Testing and Test Cases

Thanks for your diligent reply, Laurent. It has been very helpful and> interesting.>

I think I follow you and believe that my understanding has been correct> so far. What still intrigues me is:>

1. What then, are pre-conditions?>

My initial assessment showed they were conditions to test inside the> function's implementation, before the function returned valid input. If> they're not that, what are they?

2. I understood the unit-test script you wrote called> testIsValidContract. You tested it for one condition/validation, and as> it concurs with my understanding, you imply that it must extend for all> such validations. Fine. But what about test-cases. You said, they are a> specification of what input the function gets and what it spits out. My> question precisely is, "what is the format in which they are written?"> Could you please produce a list of test-cases for this example we've> taken? That would give me an outline.

My initial assessment showed they were conditions to test inside the> function's implementation, before the function returned valid input.

But what about test-cases. You said, they are a> specification of what input the function gets and what it spits out. My> question precisely is, "what is the format in which they are written?"

1. What then, are pre-conditions?>

My initial assessment showed they were conditions to test inside the> function's implementation, before the function returned valid input. If> they're not that, what are they?

Thanks for your diligent reply, Laurent. It has been very helpful and> interesting.>

I think I follow you and believe that my understanding has been correct> so far. What still intrigues me is:>

1. What then, are pre-conditions?>

My initial assessment showed they were conditions to test inside the> function's implementation, before the function returned valid input. If> they're not that, what are they?

Water Cooler v2 wrote:>

Thanks for your diligent reply, Laurent. It has been very helpful and> > interesting.> >

I think I follow you and believe that my understanding has been correct> > so far. What still intrigues me is:> >

1. What then, are pre-conditions?> >

My initial assessment showed they were conditions to test inside the> > function's implementation, before the function returned valid input. If> > they're not that, what are they?>

They are the client's part of the routine's contract.>

It is up to the client's to ensure a routine precondition> *before* a call is attempted (however, a wise supplier> should protect itself from erroneous preconditions, as> explained below).

In return, the client will be ensured *after* its> execution - if the routine is correct - that> the routine's postconditions will hold.>

Another very important assertion in the OO world> are class invariants. Invariants are conditions required> to hold immediately before and immediately after any> use of an object (those periods are named: object> stable times).>

Together these three assertions, if used correctly,> allow the programmer to express the (approximate)> semantics of the object's Abstract Data Type.>

Ideally all those assertions should be ensured> statically (at compile time), situation in which> the program would be correct (regarding> those assertions).>

However, such ideal and desirable goal is not> possible for most practical programs.> One is then faced to what to do when there> is the possibility (hopefully, very remote)> of a run-time assertion failure.>

We can identify four possible approaches to this> problematic run-time situation:>

1. Ostrich approach: Ignore the problem.>

2. Defensive programming approach: convert the> problem to the normal program control flow (if's).>

3. "All-or-nothing" approach: decorate the program> with C like "asserts" in the place of runnable assertions,> ensuring that either the program meets all of its> assertions at run-time, or else terminates with> an appropriate error message.>

4. DbC approach: make all those assertions part> of the programming language and relate them> with the exception mechanism. A failure of> an assertion raises an exception.>

Only the last two approaches are appropriate> to properly handle run-time contracts.

Water Cooler v2 wrote:>>

Thanks for your diligent reply, Laurent. It has been very helpful and>> > interesting.>> >

I think I follow you and believe that my understanding has been correct>> > so far. What still intrigues me is:>> >

1. What then, are pre-conditions?>> >

My initial assessment showed they were conditions to test inside the>> > function's implementation, before the function returned valid input. If>> > they're not that, what are they?>>

They are the client's part of the routine's contract.>>

It is up to the client's to ensure a routine precondition>> *before* a call is attempted (however, a wise supplier>> should protect itself from erroneous preconditions, as>> explained below).>

A nice write up except for this one problem. If the supplier is able to> protect itself from erroneous inputs, then it can define proper outputs> for those inputs, thus making them no longer erroneous.

Someone else's example:>

double inverse( double x ) {> return 1/x;> }>

The precondition of course is that 'x != 0' however, thats an easy thing> to check, and as such one can define a particular output for that> condition:>

// returns NaN if x == 0> double inverse( double x ) {> return 1/x;> }

On the other hand, some functions have preconditions that can't be> checked. For example C++'s std::copy takes two input iterators that must> be in a range (ie incrementing the first iterator must eventually make> it equal to the second.) This cannot be checked from inside the routine,> even theoretically. Now that's a *real* precondition.>

For real preconditions, none of the above approaches will work. You> can't ignore the problem, and you can't write code to protect yourself> from it.

-- > Magic depends on tradition and belief. It does not welcome observation,> nor does it profit by experiment. On the other hand, science is based> on experience; it is open to correction by observation and experiment.

In article <44035117.A32AC86E@det.ua.pt>,> Miguel Oliveira e Silva <mos@det.ua.pt> wrote:>

Water Cooler v2 wrote:> >

Thanks for your diligent reply, Laurent. It has been very helpful and> > > interesting.> > >

I think I follow you and believe that my understanding has been correct> > > so far. What still intrigues me is:> > >

1. What then, are pre-conditions?> > >

My initial assessment showed they were conditions to test inside the> > > function's implementation, before the function returned valid input. If> > > they're not that, what are they?> >

They are the client's part of the routine's contract.> >

It is up to the client's to ensure a routine precondition> > *before* a call is attempted (however, a wise supplier> > should protect itself from erroneous preconditions, as> > explained below).>

Someone else's example:>

double inverse( double x ) {> return 1/x;> }>

The precondition of course is that 'x != 0'

however, thats an easy thing> to check,

and as such one can define a particular output for that> condition:>

// returns NaN if x == 0> double inverse( double x ) {> return 1/x;> }

On the other hand, some functions have preconditions that can't be> checked.

For example C++'s std::copy takes two input iterators that must> be in a range (ie incrementing the first iterator must eventually make> it equal to the second.) This cannot be checked from inside the routine,> even theoretically.

Now that's a *real* precondition.

In return, the client will be ensured *after* its> > execution - if the routine is correct - that> > the routine's postconditions will hold.> >

Another very important assertion in the OO world> > are class invariants. Invariants are conditions required> > to hold immediately before and immediately after any> > use of an object (those periods are named: object> > stable times).> >

Together these three assertions, if used correctly,> > allow the programmer to express the (approximate)> > semantics of the object's Abstract Data Type.> >

Ideally all those assertions should be ensured> > statically (at compile time), situation in which> > the program would be correct (regarding> > those assertions).> >

However, such ideal and desirable goal is not> > possible for most practical programs.> > One is then faced to what to do when there> > is the possibility (hopefully, very remote)> > of a run-time assertion failure.> >

We can identify four possible approaches to this> > problematic run-time situation:> >

1. Ostrich approach: Ignore the problem.> >

2. Defensive programming approach: convert the> > problem to the normal program control flow (if's).> >

3. "All-or-nothing" approach: decorate the program> > with C like "asserts" in the place of runnable assertions,> > ensuring that either the program meets all of its> > assertions at run-time, or else terminates with> > an appropriate error message.> >

4. DbC approach: make all those assertions part> > of the programming language and relate them> > with the exception mechanism. A failure of> > an assertion raises an exception.> >

Only the last two approaches are appropriate> > to properly handle run-time contracts.>

For real preconditions, none of the above approaches will work.

You can't ignore the problem, and you can't write code to protect yourself> from it.

--> Magic depends on tradition and belief. It does not welcome observation,> nor does it profit by experiment. On the other hand, science is based> on experience; it is open to correction by observation and experiment.

In article <44035117.A32AC86E@det.ua.pt>,> Miguel Oliveira e Silva <mos@det.ua.pt> wrote:>

Water Cooler v2 wrote:>>

Thanks for your diligent reply, Laurent. It has been very helpful and>>>interesting.>>>

I think I follow you and believe that my understanding has been correct>>>so far. What still intrigues me is:>>>

1. What then, are pre-conditions?>>>

My initial assessment showed they were conditions to test inside the>>>function's implementation, before the function returned valid input. If>>>they're not that, what are they?>>

They are the client's part of the routine's contract.>>

It is up to the client's to ensure a routine precondition>>*before* a call is attempted (however, a wise supplier>>should protect itself from erroneous preconditions, as>>explained below).>

A nice write up except for this one problem. If the supplier is able to > protect itself from erroneous inputs, then it can define proper outputs > for those inputs, thus making them no longer erroneous.>

Someone else's example:>

double inverse( double x ) {> return 1/x;> }>

The precondition of course is that 'x != 0' however, thats an easy thing > to check, and as such one can define a particular output for that > condition:>

// returns NaN if x == 0> double inverse( double x ) {> return 1/x;> }

In article <44035117.A32AC86E@det.ua.pt>,> > Miguel Oliveira e Silva <mos@det.ua.pt> wrote:> >

Water Cooler v2 wrote:> >>

Thanks for your diligent reply, Laurent. It has been very helpful and> >>>interesting.> >>>

I think I follow you and believe that my understanding has been correct> >>>so far. What still intrigues me is:> >>>

1. What then, are pre-conditions?> >>>

My initial assessment showed they were conditions to test inside the> >>>function's implementation, before the function returned valid input. If> >>>they're not that, what are they?> >>

They are the client's part of the routine's contract.> >>

It is up to the client's to ensure a routine precondition> >>*before* a call is attempted (however, a wise supplier> >>should protect itself from erroneous preconditions, as> >>explained below).> >

A nice write up except for this one problem. If the supplier is able to > > protect itself from erroneous inputs, then it can define proper outputs > > for those inputs, thus making them no longer erroneous.> >

Someone else's example:> >

double inverse( double x ) {> > return 1/x;> > }> >

The precondition of course is that 'x != 0' however, thats an easy thing > > to check, and as such one can define a particular output for that > > condition:> >

// returns NaN if x == 0> > double inverse( double x ) {> > return 1/x;> > }>

Although you could specify it to return a silent NaN that merely delays > detecting a hard error and contaminates other possibly meaningful future > calculations that use this NaN result.>

Generating a trap in most cases would be preferable since it usually > signifies a serious programming error when division by zero occurs.

Your improved definition potentially breaks some code that might be > expected to work algebraically since you can no longer satisfy the > invariant property for the function inverse for all valid inputs.>

x == inverse( inverse(x) )>

whereas 0 != inverse( inverse(0)) under your definition.>

And at present inverse(Nan) is also undefined.

It seems to me, that you are incorrectly mixing the world> of normal program behavior, and the world of exceptions> and exceptional behavior.

Exceptions exist as a> mean to deal with (detectable) incorrect programs> (in DbC it is as simply as this).

and as such one can define a particular output for that>> condition:>>

// returns NaN if x == 0>> double inverse( double x ) {>> return 1/x;>> }>

You surely can, but you surely shouldn't (or else> you will be doing defensive programming and not> DbC).

Now that's a *real* precondition.>

What do you mean by "real"?

(Surely you are not stating that runnable> preconditions are not real!)

On Tue, 28 Feb 2006 16:38:41 +0000, Miguel Oliveira e Silva wrote:>

It seems to me, that you are incorrectly mixing the world> > of normal program behavior, and the world of exceptions> > and exceptional behavior.>

A behavior is either correct or not. A program exposing incorrect behavior> is incorrect. [That correctness might be undecidable changes here nothing.]

Exceptions exist as a> > mean to deal with (detectable) incorrect programs> > (in DbC it is as simply as this).>

Exceptions are used for control flow in correct programs.

Exceptions in incorrect programs are presumably incorrect.

and as such one can define a particular output for that> >> condition:> >>

// returns NaN if x == 0> >> double inverse( double x ) {> >> return 1/x;> >> }> >

You surely can, but you surely shouldn't (or else> > you will be doing defensive programming and not> > DbC).>

Extended numeric sets are proven to be mathematically correct and deliver> far safer and efficient computations than ones defined on bound numeric> subsets. NaN is a *legal* value of IEEE float.

It is a valid outcome of> division a finite number by exact zero. Better could be only full-scaled

interval arithmetic with infinity ideals.>

Now that's a *real* precondition.> >

What do you mean by "real"?>

= used to determine correctness of the program.

(Surely you are not stating that runnable> > preconditions are not real!)>

That is the only possibility, as I have shown in our previous discussion.

I think there is no need to repeat it.

--> Regards,> Dmitry A. Kazakov> http://www.dmitry-kazakov.de

On Tue, 28 Feb 2006 16:38:41 +0000, Miguel Oliveira e Silva wrote:>>

"Daniel T." wrote:>>

Exceptions are used for control flow in correct programs.>

Not in DbC. That would be an unacceptable abuse of exceptions.>

A correct program should never raise exceptions.

In DbC, exceptions are used to deal with incorrect programs> (broken contracts).>

Exceptions in incorrect programs are presumably incorrect.>

Nope. They *correctly* signal an *incorrect* program> (as in physical sciences when an experience whose results> contradicts what was expected from a theoretical law,> proves *correctly* that the law is *incorrect*).

No it is not. It is only necessary a little effort to understand> what I'm saying, and what DbC is.> [B. Meyer, Object-Oriented Software Construction, 2ed,> pages 331-438]

"Miguel Oliveira e Silva" <mos@det.ua.pt> wrote in message > news:4404AB97.37B38F68@det.ua.pt...> > "Dmitry A. Kazakov" wrote:> >

On Tue, 28 Feb 2006 16:38:41 +0000, Miguel Oliveira e Silva wrote:> >>

"Daniel T." wrote:> >>

Exceptions are used for control flow in correct programs.> >

Not in DbC. That would be an unacceptable abuse of exceptions.> >

A correct program should never raise exceptions.>

What if the contract specifically states that the behaviour of a given > method is to raise an exception?

In DbC, exceptions are used to deal with incorrect programs> > (broken contracts).> >

Exceptions in incorrect programs are presumably incorrect.> >

Nope. They *correctly* signal an *incorrect* program> > (as in physical sciences when an experience whose results> > contradicts what was expected from a theoretical law,> > proves *correctly* that the law is *incorrect*).>

Not nescessarily, as shown above (i.e. the exception might correctly be > part of the behaviour of a correctly implemented program). However, if a > program is incorrectly implemented, then perhaps the exception raising > routines are also incorrectly implemented, so raising the exception might > not be a correct signal for anything!

/*> Pre-condition: none.> Post-condition: "Hello World!" is printed to the standard out, no exception > will be raised.> */> void printHelloWorld() {> print "Hello World!"> throw new DivideByZeroException();> }>

This program is incorrectly implemented, and coincidentally an exception > is raised. But the exception being raised is *INCORRECTLY* signalling the > the incorrectness of the program; it claims that the problem had something > to do with a division by zero, when that was not the nature of the > incorrectness at all. Actually, the incorrectness was simply the presence of > the exception itself!

"Dmitry A. Kazakov" wrote:>

On Tue, 28 Feb 2006 16:38:41 +0000, Miguel Oliveira e Silva wrote:>>

Exceptions exist as a>>> mean to deal with (detectable) incorrect programs>>> (in DbC it is as simply as this).>>

Exceptions are used for control flow in correct programs.>

Not in DbC. That would be an unacceptable abuse of exceptions.>

A correct program should never raise exceptions.

Exceptions in incorrect programs are presumably incorrect.>

Extended numeric sets are proven to be mathematically correct and deliver>> far safer and efficient computations than ones defined on bound numeric>> subsets. NaN is a *legal* value of IEEE float.>

I fail to see suitable uses of a NaN number ("Not-a-Number" number)> other than to express an error within the number representation,

but - by all means - be free to use that defensive approach to> inverse [inverse(0) = NaN].

Just don't forget that the inverse function (as all functions) are> is not an end in it selves, but a mean to reach somewhere.> I'll bet that in 99.99...99% if the times the client of inverse> is not expecting to divide by zero, neither such result makes> any sense to whatever calculation required the use of this> function.

Now that's a *real* precondition.>>>

What do you mean by "real"?>>

= used to determine correctness of the program.>

Are you saying that the non-zero x precondition> of inverse is not useful to determine the correctness> of a program?

(Surely you are not stating that runnable>>> preconditions are not real!)>>

That is the only possibility, as I have shown in our previous discussion.>

(I missed that demonstration.)

If that is your opinion, then don't call it DbC, or else you> will be confusing everyone who does not know what is> this methodology.

"Miguel Oliveira e Silva" <mos@det.ua.pt> wrote in message> news:4404AB97.37B38F68@det.ua.pt...> > "Dmitry A. Kazakov" wrote:> >

On Tue, 28 Feb 2006 16:38:41 +0000, Miguel Oliveira e Silva wrote:> >>

"Daniel T." wrote:> >>

Exceptions are used for control flow in correct programs.> >

Not in DbC. That would be an unacceptable abuse of exceptions.> >

A correct program should never raise exceptions.>

What if the contract specifically states that the behaviour of a given> method is to raise an exception?

/*> Pre-conditions: None.> Post-conditions: NullPointerException must be raised.> */> void raiseNPE() {> /*Implementation goes here*/> }>

In DbC, exceptions are used to deal with incorrect programs> > (broken contracts).> >

Exceptions in incorrect programs are presumably incorrect.> >

Not nescessarily, as shown above (i.e. the exception might correctly be> part of the behaviour of a correctly implemented program).

However, if a> program is incorrectly implemented, then perhaps the exception raising> routines are also incorrectly implemented, so raising the exception might> not be a correct signal for anything!

/*> Pre-condition: none.> Post-condition: "Hello World!" is printed to the standard out, no exception> will be raised.> */> void printHelloWorld() {> print "Hello World!"> throw new DivideByZeroException();> }>

This program is incorrectly implemented, and coincidentally an exception> is raised. But the exception being raised is *INCORRECTLY* signalling the> the incorrectness of the program;

it claims that the problem had something> to do with a division by zero, when that was not the nature of the> incorrectness at all.

Actually, the incorrectness was simply the presence of> the exception itself!

In article <aF2Nf.7647$Cp4.7169@edtnps90>,> "Oliver Wong" <owong@castortech.com> wrote:>

"Miguel Oliveira e Silva" <mos@det.ua.pt> wrote in message> > news:4404AB97.37B38F68@det.ua.pt...> > > "Dmitry A. Kazakov" wrote:> > >

On Tue, 28 Feb 2006 16:38:41 +0000, Miguel Oliveira e Silva wrote:> > >>

"Daniel T." wrote:> > >>

Exceptions are used for control flow in correct programs.> > >