Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.lang.eiffel
Subject: Assertions (was: Re: Eiffel vs. C++)
Keywords: Assertions
Message-ID: <136@ssp1.idca.tds.philips.nl>
Date: 12 Jun 89 19:32:19 GMT
References: <807@batserver.cs.uq.oz>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 38

In article <807@batserver.cs.uq.oz> bigm@batserver.cs.uq.oz writes:

>> better than the assertions dreamed up by the programmer, I'm skeptical of
>> using it to "replace" unit testing.
>
Read below.

>1. Carefully chosen assertions clarify your understanding of the code
>   you are writing or reading and force you to reason about what you
>   are really doing and it's consequences. I have found this to be
>   the most important benifit. 

My experience also.

>
>		When I did the group software project I was the only one to
>		use assertions.  During intergration, people would run to me
>		saying YOUR module had ANOTHER assertion failure.  More often
>		than not, I had the pleasure of replying "Oh, that means your
>		not sorting that array you passed me like you were supposed to."

One mans pleasure is another mans...

I had exactly the same experience the system kept breaking down in _my_
code because I was trapping everybody else's bugs. So _I_ got to figure 
out each time whose problem it really was :-(

Meanwhile people started noticing that the system seemed to breaking down
more often in _my_ code than in other peoples :-( :-(
 
>I have personally found the use of assertions to save me 80% of my previous
>debugging time and effort. 

My experience too. Turned out we were able to skip the whole unit test.
Code just upped and ran :-) :-)
-- 
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof