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: a07f3367d7,be506f30028794c1
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!192.87.166.28.MISMATCH!tudelft.nl!txtfeed1.tudelft.nl!feeder.erje.net!fi.sn.net!newsfeed2.tdcnet.fi!news.song.fi!not-for-mail
Date: Fri, 05 Mar 2010 08:41:19 +0200
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Organization: Tidorum Ltd
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Testing a package's internal details.
References: <4b90563a$0$2345$4d3efbfe@news.sover.net>
In-Reply-To: <4b90563a$0$2345$4d3efbfe@news.sover.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4b90a79c$0$2002$4f793bc4@news.tdc.fi>
NNTP-Posting-Host: 81.17.205.61
X-Trace: 1267771292 news.tdc.fi 2002 81.17.205.61:49838
X-Complaints-To: abuse@tdcnet.fi
Xref: g2news1.google.com comp.lang.ada:9412
Date: 2010-03-05T08:41:19+02:00
List-Id: <comp.lang.ada>

Peter C. Chapin wrote:
> 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?

I've seen two ways to do this:

- First way: As you suggest, above, but make the test procedure 
(Internal_Tests) be separately implemented ("is separate" as the body). 
This at least removes the code for the internal tests into a separate 
file. By juggling with the compiler's search paths you can use a null 
form of Internal_Tests for your production software.

- Second way: Make the *internals* into a private child of the public 
main package:

package Test_Me is
    -- Just the public operations:
    procedure Public_Operation;
end Test_Me;


private package Test_Me.Internals is
    -- Declarations of all the "internals" that you
    -- want to test, plus all of the operations that you
    -- want to make public.
    procedure Internal_Operation;
    procedure Public_Operation;
end Test_Me.Internals;


with Test_Me.Internals;
package body Test_Me is
    -- Route (by renamings or calls) all public operations
    -- to their implementations in Test_Me.Internals:
    procedure Public_Operation
    renames Internals.Public_Operation;
end Test_Me;


Then write the test procedure as a child:

procedure Test_Me.Internals.Test is
begin
    Internal_Operation;
end Test_Me.Internals.Test;


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .