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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-10 08:07:49 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? Date: 10 Oct 2003 10:59:05 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3F7F760E.2020901@comcast.net> <3F8035B0.7080902@noplace.com> <3F816A35.4030108@noplace.com> <3F81FBEC.9010103@noplace.com> <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F846B5E.9080502@comcast.net> <3F855460.6020804@noplace.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1065798139 17872 128.183.235.92 (10 Oct 2003 15:02:19 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 10 Oct 2003 15:02:19 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Xref: archiver1.google.com comp.lang.ada:606 Date: 2003-10-10T15:02:19+00:00 List-Id: Stefan Lucks writes: > On 9 Oct 2003, Stephen Leake wrote: > > > Stefan Lucks writes: > > > > 1. a unit test for the package and > > > > I find Aunit to be a good unit test framework (see > > http://savannah.nongnu.org/projects/grace/ for a working example). > > You missed my point! Well, I didn't. There are two points here; 1) how to write the unit tests 2) how to invoke the unit tests. Aunit is an answer to point 1. > Think of a "customer" (i.e., any programmer who wants to "with" the > library) and call her A. A somehow (perpaps by downloading it from > the web site) gets her hands on the source code of some library > packages. The very first thing she will (or at least should) do is > to ask each package: "Are you okay?" ("Is this package compiling > under my compiler and running on my target platform under my target > platform's configuration?") > > The best way to answer this question is to run the entire battery of unit > tests which have been used by the author of the library package. Yes. That's point 2). > I would want to provide A with a simple button to fire the test > battery. And this button should be at the same place and have the > same shape and color for all packages of the standard library! Yes. My answer is "from you normal command line, run 'make test'". Your answer appears to be "somehow run code that invokes Foo.Self_Test". > It is a non-issue for A, which test framework has been used by the > author of the library package. Well, it matters a little, if it affects the answer to point 2). But it mostly doesn't matter. > > > 2. checking the current version number of package > > > We could require each top-level package to provide a Version function, > > that returns a string. > > I had been thinking of that. However, natural sting comparison is > different from comparing version numbers: > "14.3" < "3.14" (Ouch!) Ah. I missed that you wanted them at runtime. Yes, that would require two or three integers. Or convert to float first :). > OK, so use > > some.weird.package_name.Self_Test.Full_Self_Test(0); > > instead. (However, I don't quite buy your wast-of-space reason. Any > decent linker is able to throw away unused subprograms, right?) In a perfect world, yes. But no current linker (that I use or am aware of) does this. There's also the information hiding and general code organization issue; unit test code is a different beast than implementation code, and doesn't belong in the same package. > Didn't Lady Ada free us from using makefiles? :-) >From parts of them, yes; the makefile no longer has to specify the Ada source file dependencies. But as I have said before here, there is much more to a real project than the Ada source code. > And who said that the auxiliary packages should be children? Just > "with" them, when implementing your tests. If this does not compile > because the "with"ed toolbox is not available, A has no chance to do > these tests by herself anyway, even if she'd run make. Sometimes you need visibility into the private part to implement a good unit test; that means at least some of the unit test has be a child package. > (I can imagine some special cases and exceptional circumstances, where > your test needs external files, system- or platform-specific information, > ... This prevents providing the full test battery, i.e. Full_Self_Test > can't be implemented. Sometimes, even a reduced test battery could be > useful -- call it Main_Self_Test instead of Full_...) I don't accept that a full unit test "can't be provided". If you can't test it, it doesn't do anything real :). Maybe it's hard or expensive; that's different. That would have to be one of the library policies; how expensive can the unit tests be? > > Hmm. I guess you mean one package depends on specific versions of > > other packages, > > I think, you missed my point again. Think as a "customer" A. > > Consider an application with-ing some library package X version y.z. Ada can't say "version y.z" in a with clause (and no, I don't think we want a language extension for that :). But I think I know what you mean. Let's call the Application Y; the last time Y was tested, it used X version y.z. > There is an implementation of X available, and its version number is v(X). > > If v(X) = y.z, then fine! Right. Hopefully, this is tested at configure time (pre compile-time; I'm thinking Gnu configure, or rpm). > If v(X) < y.z, this may indicate great trouble. (However, perhaps A can > download and install a more recent version of X.) Right. > A's reaction on v(X) > y.z, may depend on her trust in the > upward-compatibility of the development of X ... At least for saftety- or > security-critical programs (and that is still the area where Ada is best > for), it would be prudent to check for things that may be broken by using > a version of X which is newer than y.z. The least thing I'd do would be to > read the changes-log of X. Right. > My point is, I don't want A to *manually* compare y.z with v(X). (There > may be many Xs, and thus many pairs (v(X),y.z).) It is much better to do > these tests automatically, either at compile time or at least (early) at > test time. Right. That's what rpm does. I haven't used it much, but it seems to do it well. And it does it before compile time, which is even better. > The Ada compiler is a great tool, so use it to simplify your life! > :-) Um, the Ada compiler can't do this. Unless we extend Ada with "pragma Version" or something. Is that what you are proposing? You can write code that uses the Foo.Version function, and compares it against an expected version. Maybe that's what you are proposing. But that's at run-time, which is way too late. I would only use Foo.Version in a Help | About box, and in error logs. -- -- Stephe