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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,be506f30028794c1,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!novia!transit4.readnews.com!news-out.readnews.com!postnews3.readnews.com!not-for-mail Message-Id: <4b90563a$0$2345$4d3efbfe@news.sover.net> From: "Peter C. Chapin" Subject: Testing a package's internal details. Newsgroups: comp.lang.ada Date: Thu, 04 Mar 2010 19:57:48 -0500 User-Agent: KNode/0.10.9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Organization: SoVerNet (sover.net) NNTP-Posting-Host: 508517bf.news.sover.net X-Trace: DXC==I`Y^n9YMVEY2OmIRT>9jNK6_LM2JZB_C=Elkb0T[W3@:WUUlR<856Og_[JX A situation has come up for me and I'm wondering what the "best" way is to handle it. Here are the particulars... I have a package that models a single abstract object. The specification declares the operations that are allowed on the object. I would like to write some test procedures that can be used to exercise my implementation. Using a test program that exists outside the package, I can treat the package like a black box and call the public interface to the package during my tests. That is fine. However, I'd also like to write some test procedures that independently exercise certain internal facilities without being constrained by the public interface. Those procedures are not really part of the abstraction I'm trying to present and I don't really want normal client code to call them. I do want the test program to call them, of course. Is there a "best practice" in this area that I should be following? At first I thought I might be able to make my test procedures part of a child package but that doesn't work because a child package has no access to the internal part of the parent's body (true?). I suppose I could declare the test procedures in the private part of the parent's specification and then provide a child with a public procedure that just calls the parent's private test procedure. Something like package Test_Me is -- ... private procedure Internal_Tests; end Test_Me; package Test_Me.Tester is procedure Do_Tests; -- Call Test_Me.Internal_Tests (+ other stuff) end Test_Me.Tester; Is there a more elegant or appropriate way? Thanks! Peter