Laziness aside, redundant test composing increases the risk of expectation errors. Wanting to get rid of redundancy is an excellent goal.

One part of the answer is to take a step back an analyze your test suite the same way you do any other pile of code: separate the data from the logic. If you have a group of tests that are the same except for some inputs and expected values, move the inputs and expected values into arrays and hashes. Then write a test suite function that takes those arrays and hashes as a parameter and runs all of the tests. I write almost all my tests this way and it is a life saver.

Another trick is to group inputs according to expected value. Next write a test suite function that takes an array of inputs, and one expectation. Inside the function loop through the inputs calling your test suite function with the current input and the expected value.

This is a great way to make sure that the default values really default as they should: one of the inputs contains no undefined values; the rest of the inputs replace parameters that just happen to equal the default value with undef (or omit them all together if at the end). Whether or not a defined or undefined value is in the parameter array, if your default rules are working properly they should have the same expectations. It is also a good way to make sure that exceptions and warnings are being thrown as they should be: in this case your input group is bunch of inputs that are expected to all trigger the same exceptions and warnings.

Best, beth