Testing a package's internal details.

["Peter C. Chapin" <pcc482719@gmail.com>]

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