Consider a design that has not only inheritance but composition, maybe like:

package A;
...
package A::a;
use base 'A';
...
package A::b;
use base 'A';
...
package B;
use A; # A is abstract and contains 'factory' methods, so we
       # will actually use instances of A::a or A::b
...
package C;
use B;
...
package D;
use C;
use XYZ; # not our code...something we installed
...
[download]

Is part of your question how to write tests for D that will cover all the stuff in the included packages? That's a good question...I'm curious to find out The Answer™, but I think halley was on the right track.

From my own experience, this is simply one of those areas where you have to work from bottom to top: write the tests for A (including its subclasses), then those for B, and on up.

My insight, shallow as it might be, is based on a toy program (an "address book") I'm experimenting with. Substitute the following:

generic module	address book module
A	ContactResource
A::a	Address
A::b	Phone
A::c (yes, I know it's not in the example above)	Email
B	Person
C	AddressBook
D	AddressBookApplication (the difference between this and AddressBook is that the former is mosly a data structure while this has the application and session logic: sign in, maintain session state, move from page to page, add/update/delete entries from the address book, etc.)
XYZ	DBI, CGI::Application, etc.

The tests require some thought and planning. I have separate test cases for the simplest cases (A::a), and slowly work up to the bigger ones (so far up to the C level).

To me it seems test design gets more complex if you want to "automate" testing. For example, lots of things in my toy app depend on the data available in backend database. I anticipate (unless The Answer™ proves otherwise) that I'll have to include in any automatic test scripts the creation and population of a test database.

So, I don't think I've really answered your question; it seems to be my question also (unless they're not really the same question and I'm projecting mine onto yours :-)).

Update: Another post has given me some more things to think about with respect to the question.

---

...every application I have ever worked on is a glorified munger...

---

In reply to Re: (OT) Help with test design by t'mo
in thread (OT) Help with test design by dragonchild

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.