Re: ADA Popularity Discussion Request

["Randy Brukardt" <randy@rrsoftware.com>]

"Kevin Cline" <kevin.cline@gmail.com> wrote in message
news:e749549b.0409101623.73cdaf9b@posting.google.com...
> "Randy Brukardt" <randy@rrsoftware.com> 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.