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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 13 Sep 2004 19:16:13 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> <2L-dnRmP6qOePaLcRVn-ug@megapath.net> Subject: Re: ADA Popularity Discussion Request Date: Mon, 13 Sep 2004 19:17:07 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-JVPhJwV7FdhNl3oHbq6uluh1KKI+klNz3fZPoDP/uplvw9aIprRGwm1Dqj6s4BwsOWz9GXo/QjahuiM!RTK/EAsllIz9miRhPDMGpu1kVf8ZfXBUBV3cgrU8b/r2EvsFka5ccP2C5+JXj/ZbOcHFf53qlBSZ X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.13 Xref: g2news1.google.com comp.lang.ada:3701 Date: 2004-09-13T19:17:07-05:00 List-Id: "Kevin Cline" wrote in message news:e749549b.0409101623.73cdaf9b@posting.google.com... > "Randy Brukardt" wrote in message news:<2L-dnRmP6qOePaLcRVn-ug@megapath.net>... ... > > This seems like complete nonsense to me. (I'll admit that I've read other > > people making similar claims). The reason is that writing a good subprogram > > test takes on average 10 times as much code as is in the subprogram itself. > > > That's because of the need to set up the needed global state for the > > preconditions, and the need to test all of the possible permutations of > > input. Making the test reusable and automatible adds even more effort. > > A 10:1 ratio of test code to production code seems extremely high. > Keeping subprograms small will reduce the number of permutations of > input that must be tested. It's much easier to test five ten-line > subprograms taking one input each than to test one fifty-line > subprogram taking five inputs. The size of the subprogram is irrelevant. In real systems, there is a lot of state associated with any particular operation. You have to set up all of that state in order to have a useful, repeatable test. For instance, in the Janus/Ada compiler, we have lots of short query functions. But you have to have a complete symboltable in order to use them - otherwise their preconditions would be violated and the test results would tell you nothing. > It's also much easier to maintain the five ten-line subprograms, and > easier to demonstrate code correctness. While I don't doubt that, it's rare that you can write anything useful in 10 lines of readable code. (Sure, you can cram lots of code into that space, especially in languages like Lisp or Perl; but is there any chance to fix it when a problem is discovered in a few months? Not if the code isn't readable.) > Another benefit of unit-level testing is that in the absence of any > other documentation, the tests at least demonstrate correct use of the unit. Yes, that's the main reason that we even bothered with many of the tests we wrote for Claw. (They also served to verify that the Microsoft documentation was accurate, a real dicey proposition in 1997.) > > The best way to save time and money is to avoid the need to do that testing > > in the first place. We do that with Ada's strong compile-time and run-time > > checking, combined with occassional invariant assertions. And then we do > > extensive, repeatable system-level testing to find any logic errors. > > I do not like having only system-level testing because it makes > changes either risky or expensive, and inhibits refactoring. It > drives developers to stick with the first code that passes tests, and > inhibits extraction of duplicated code because of the cost of > retesting. Changes certainly aren't risky in Ada, and a majority aren't expensive, either. Refactoring (indeed, any sort of restructuring) is a complete waste of effort unless it is tied to a clear end-user benefit. We used to do lots of that, but it mainly made us (the programmers) feel good, and it did nothing to make the product better in many of the cases. Your last sentence seems to go against agile - test-driven - methods -- once the tests pass, you're done! There's no reason to mess with the code further. Moreover, there is little cost to retesting, because the tests are all automated and run pretty much after every change. Testing is not very worthwhile in my view if you can't rerun it frequently to verify that nothing has changed. Randy.