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,
	T_FILL_THIS_FORM_SHORT 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!news1.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Testing a package's internal details.
References: <4b90563a$0$2345$4d3efbfe@news.sover.net>
From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Fri, 05 Mar 2010 06:31:56 -0500
Message-ID: <usk8fvwb7.fsf@stephe-leake.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt)
Cancel-Lock: sha1:Tb9sret7JSHQwmLEI3M0hTGtFDQ=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 31b574b90ebcde197caa718823
Xref: g2news1.google.com comp.lang.ada:9424
Date: 2010-03-05T06:31:56-05:00
List-Id: <comp.lang.ada>

"Peter C. Chapin" <pcc482719@gmail.com> writes:

> 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.

Ok so far.

> 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?). 

Right.

> 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.

Better to make the actual operations visible in the private part:

package Test_Me is
  -- ...
private
  procedure Private_Op_1;
  function Private_Op_2 return string;
end Test_Me;

package Test_Me.Tester is
  procedure Test_Private_Op_1;
  procedure Test_Private_op_2;
end Test_Me.Tester;

Or, if the private ops are fairly complicated, and use complicated
types, move them to a separate private package:

package Test_Me is

end Test_Me;

private
package Test_Me.internals is
end test_me.internals;

with test_me.internals;
package body test_me is

    -- stuff that uses test_me.internals

end test_me;

private
package test_me.internals.tester is

...
end test_me.internals.tester;

To work with a framework like AUnit, you sometimes have to declare a
public access package:

package Test_Me.internals_aux is

    procedure private_op_1; 

end test_Me.internals_aux;

Test_Me.internals_Aux.private_op_1 calls the real
test_me.internals.private_op_1.

-- 
-- Stephe