From: Stephen Leake <stephen_leake@stephe-leake.org>
Subject: Re: Testing a package's internal details.
Date: Fri, 05 Mar 2010 06:31:56 -0500
Date: 2010-03-05T06:31:56-05:00 [thread overview]
Message-ID: <usk8fvwb7.fsf@stephe-leake.org> (raw)
In-Reply-To: 4b90563a$0$2345$4d3efbfe@news.sover.net
"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
prev parent reply other threads:[~2010-03-05 11:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-05 0:57 Testing a package's internal details Peter C. Chapin
2010-03-05 6:41 ` Niklas Holsti
2010-03-05 11:25 ` Peter C. Chapin
2010-03-05 11:31 ` Stephen Leake [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox