roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (06/13/89)
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
diamond@diamond.csl.sony.junet (Norman Diamond) (06/14/89)
In article <136@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes: >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 :-( :-( Hmm. I guess the real world needs assertions that print out WARNING messages and then continue executing with incorrect results. And maybe even the warnings should be directed to /dev/null unless the execution-time invoker matches the the compile-time developer. (I wish this were rhetorical....) -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
alonzo@microsoft.UUCP (Alonzo Gariepy) (06/16/89)
In article <10368@socslgw.csl.sony.JUNET> diamond@csl.sony.junet > >Hmm. I guess the real world needs assertions that print out WARNING >messages and then continue executing with incorrect results. And >maybe even the warnings should be directed to /dev/null unless the >execution-time invoker matches the the compile-time developer. >(I wish this were rhetorical....) >-- >Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The real world has assertions that do exactly that and there is no reason to wish your comment was rhetorical. Ignorable assertions are a major convenience in debugging and testing and make for robust system code. It is frustrating to have a debugging session stopped dead by an assertion, and it is often convenient to redirect warning messages to /dev/null so that they don't mess up the debug output you are interested in. In released code (especially system software) assertions can check for and report illegal parameters, but continue execution with reasonable defaults so that programs are still functional. Once such an error is reported, it might be nice to redirect such messages to /dev/null until such time as the problem is fixed. Such assertions are also handy when it is found that illegal parameters have been slipping through and taking advantage of undocumented side-effects. Future versions of a library can assert the legality of parameters without breaking existing programs. Ideally, we would all like a programming language that will tell us when we are not being precise, but which can figure out what we really meant and tell us before going off to do it. For maintenance reasons it should also modify the code to be more precise once we have accepted its interpretation.