this is my second attempt at "test-first" design, and it's making me beat my head against the wall BEFORE i have much code written, so i guess that's a good thing™

Being a bit of a TDD bigot I'd be interested in understanding what forces are encouraging you to write tests like this. About the only time I write tests that look at, for want of a better term, the generic "shape" of a data structure are when I'm debugging somebody else's code.

When I'm writing fresh code looking at the generic "shape" doesn't really help me write the next bit of code. Looking at progressively more complex concrete instances of the returned data does.

From what you've written so far I don't really understand exactly what foundation_list() does, but would a progression of tests that look something like this make sense to you?

is_deeply( $empty->foundation_list, [], 'empty foundation list' );

is_deeply( $one_option->foundation_list, [ { a => 'b' } ], 
    'single  option foundation list' );

is_deeply( $two_options->foundation_list, [], [ { a => 'b', c => 'd'} 
+],
    'two option foundation list' );
[download]

The idea being that each test would encourage me to write a little bit of code that makes that particular test pass. Develop by increments and refactor all of the time, rather than do everything in large chunks.

Make vague sense?

Being a bit of a TDD bigot I'd be interested in understanding what forces are encouraging you to write tests like this. About the only time I write tests that look at, for want of a better term, the generic "shape" of a data structure are when I'm debugging somebody else's code.

well, the changes i'm making to the application are twofold:

1. migrating the entire codebase to a new database schema. the first design of this was "shopping cart" based, and the application has outgrown that to become more of an event building and attendance reporting tool. since the underlying database has changed (dramatically), i want to make sure that i'm not ending up with empty option lists, etc. i'd rather catch that at the command-line (w/ `make test` than wait until i'm in step 5 of the webapp)
2. adding an entirely new workflow that's grafted into the existing one. i don't have the time or gumption to throw away the entire codebase and start from scratch, even though the app could use it. there are way too many return $q->redirect type routines .... it's just such a buggy, fragile application that i want test surrounding every change i make.
so in this specific case, i'm testing the fact that the routine returned a list of hashrefs that will be fed into HTML::Template to build a popup_menu ... and if i change my mind about that and pass it into CGI to build the list (and let CGI handle selected values, etc), then i have that tested as well ...

migrating the entire codebase to a new database schema. the first design of this was "shopping cart" based, and the application has outgrown that to become more of an event building and attendance reporting tool. since the underlying database has changed (dramatically), i want to make sure that i'm not ending up with empty option lists, etc. i'd rather catch that at the command-line (w/ `make test` than wait until i'm in step 5 of the webapp)

And that's perfectly reasonable. But wouldn't it be even better to check that you have got the correct option list, rather than just something that is the same "shape" as the correct option list?

Just testing for the "shape" is a trickier test to write, and gives you less useful feedback since incorrect return values that have the correct "shape" will pass the test.

i do like that ... i was being a bit lazy with the testing, since i just realized i may have to change my class layout ...

That is what is so great about Test::Deep (IMO of course) is that once you get your head around the declarative API, you can test some seriously large and complex structures very quickly and easily, and also be able to change those tests just as easily.