Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: (OT) Help with test design

by t'mo (Pilgrim)
on Sep 11, 2003 at 17:41 UTC ( [id://290765] : note . print w/replies, xml ) Need Help??

in reply to (OT) Help with test design

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

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 moduleaddress book module
A::c (yes, I know it's not in the example above)Email
DAddressBookApplication (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.)
XYZDBI, 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...

Replies are listed 'Best First'.
Re: Re: (OT) Help with test design
by sandfly (Beadle) on Sep 11, 2003 at 21:53 UTC
    I agree with you t'mo - where your classes interact with data in some external resource, such as a file or database, you can't test without test data.

    The best solution I've found is to script as much of the database creation and population as possible ay you suggest.