Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^5: Test::Class and test organization

by Herkum (Parson)
on Mar 22, 2006 at 13:42 UTC ( #538505=note: print w/replies, xml ) Need Help??

in reply to Re^4: Test::Class and test organization
in thread Test::Class and test organization

What it sounds like what you really want is different tests with varying level of details but only run one big test script. The thing about tests is that it cost nothing to keep making them, if you make one big test script you might spend as much time just trying to debug your test script as you would your module.

Why not start with a strategy of making a number of different tests with each one in its own file; each test has different layers of complexity. Start with small simple tests as your core and write them. As you need add complexity to your tests, focus a test on one aspect of your module. Your tests are easier to maintain because they are limited in scope. Another reason to limit the scope is that it easier for you to focus on that one piece. I cannot imagine, with the things that you are working with, trying to test everything at once. For example these could be a list of test files,

basic.t       # Basic functionality (Does a single level hash or array work?)
embedded.t    # Embedded functionality (Does a HoH, HoA, AoH, AoA, and deeper work?)
wide_data.t   # What about wide hashes and arrays (4000+ keys)?
deep_data.t   # What about deep hashes and arrays (4000+ levels)? Does every level behave appropriately? 
filter.t      # What happens if we use filters on the keys? The values?
internals.t   # What about changing some of the internal key values?
change_wide.t # Changing the hashing function make a difference?
change_deep.t #
clone.t       # Does cloning work?
import.t      # What about importing and exporting from standard Perl data structures? tied datastructures?
export.t      #
locking.t     # How about if I turn locking on and off?
dbm_deept.t   # What about creating the db using tie vs. DBM::Deep->new?
concurrent.t  # How about concurrent access?
auto_bless.t  # What about turning autobless on and off? What about locking? autoflush? 

This way might be more redundant, however, by building it in layers you will be able to more easily identify when you broke your code because the simple stuff will start breaking right away and you can focus your immediate efforts on fixing that before you attempt to address your very specific and detailed tests.

  • Comment on Re^5: Test::Class and test organization

Replies are listed 'Best First'.
Re^6: Test::Class and test organization
by dragonchild (Archbishop) on Mar 22, 2006 at 13:46 UTC
    This is exactly where the current test suite is. I'm trying to move beyond that. :-)

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://538505]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2020-01-19 19:54 GMT
Find Nodes?
    Voting Booth?