From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-13 14:32:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!news.xtra.co.nz!53ab2750!not-for-mail From: "AG" Newsgroups: comp.lang.ada References: <1054751321.434656@master.nyc.kbcfp.com> <82347202.0306101232.16776a81@posting.google.com> Subject: Re: C bug of the day X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Sat, 14 Jun 2003 09:32:55 +1200 NNTP-Posting-Host: 219.88.61.29 X-Complaints-To: newsadmin@xtra.co.nz X-Trace: news.xtra.co.nz 1055539919 219.88.61.29 (Sat, 14 Jun 2003 09:31:59 NZST) NNTP-Posting-Date: Sat, 14 Jun 2003 09:31:59 NZST Organization: Xtra Xref: archiver1.google.com comp.lang.ada:39142 Date: 2003-06-14T09:32:55+12:00 List-Id: wrote in message news:d6652001.0306130643.1e320398@posting.google.com... > > Sort of trying to compensate for deficiencies of a language with some > > home-grown solutions? > > I don't think so. Unit tests are essential, regardless of the > language. Some errors simply cannot be caught until run-time. That's right but what I meant was that all too often unit tests are used to catch the things that can and should be caught at compile time. This means two things: 1. Weakened checking compared to what compiler could do. 2. A huge number of trivial unit tests which hide and obfuscate the really inresting ones making them harder to find or even to invent. As an example, lets consider a case of a language which doesn't have the "out" parameter mode in it's method/procedure calls. Everything is passed, in effect, as "in out". So, we have something declared as: X(a, b: booleanResults; x: inputData). Turns out that internally (due to a bug) the X depends on initial input values of a & b. Once that's discovered, it needs four additional unit tests per input data to test that the bug was fixed and all input combinations of a & b work. Now, if the language had "out" parameter mode it could be used in that case and make those tests totally irrelevant - leaving more chance for a really interesting ones.