From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Testing a package's internal details.
Date: Fri, 05 Mar 2010 08:41:19 +0200
Date: 2010-03-05T08:41:19+02:00 [thread overview]
Message-ID: <4b90a79c$0$2002$4f793bc4@news.tdc.fi> (raw)
In-Reply-To: <4b90563a$0$2345$4d3efbfe@news.sover.net>
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
. @ .
next prev parent reply other threads:[~2010-03-05 6:41 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 [this message]
2010-03-05 11:25 ` Peter C. Chapin
2010-03-05 11:31 ` Stephen Leake
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox