ok( ref( $list ) eq 'ARRAY', 'returned a list' );
ok( scalar( @$list ), 'returned a populated list' );
ok( ref( $list->[0] ) eq 'HASH', 'first element is a hashref ...' );
But that IMO is only minimally testing your structure. With Test::Deep you could do this:
cmp_deeply(
$list,
all(
isa('ARRAY'),
array_each(
all(
isa('HASH'),
{ option => re(...), menu => ignore() }
)
)
)
);
This code would test that $list is an ARRAY reference, then that all the elements in it are HASH references, then it will check the structure of the hash (this part I made up as an example), to confirm that it has a key 'option' whose value matches a given reg-exp, and that it has a 'menu' key, but you can safely ignore the value in the test.
With Test::Deep you can test the entire structure while only go as deeply as needed in the specifics of that structure. It's really powerful stuff IMO :)
| [reply]
[d/l]
[select] |
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 ...
the "is each element a hashref" test was an afterthought, and i really didn't want to have to fetch out the options again just to "test" it, because it seemed to be ... more prone to error.
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™
| [reply] |
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' );
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? | [reply]
[d/l] |
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.
| [reply] |