Re^3: Test::More and is

Test::Deep just to verify that the list is, in fact, a list? I'll have to look into it.

You seem to want to do more than just that. You updated the OP to say that you wanted this:

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 ...' );
[download]

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() }
            )
        )
    )
);
[download]

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 :)

-stvn

Comment on Re^3: Test::More and is_array Select or Download Code

Replies are listed 'Best First'.
Re^4: Test::More and is_array by geektron (Curate) on Jun 10, 2005 at 20:31 UTC
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]
Re^5: Test::More and is_array by adrianh (Chancellor) on Jun 11, 2005 at 22:23 UTC
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?	[reply] [d/l]
Re^6: Test::More and is_array by geektron (Curate) on Jun 12, 2005 at 17:03 UTC
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: 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) 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 ...	[reply] [d/l]
Re^7: Test::More and is_array by adrianh (Chancellor) on Jun 13, 2005 at 11:36 UTC
Re^8: Test::More and is_array by geektron (Curate) on Jun 13, 2005 at 15:14 UTC
Some notes below your chosen depth have not been shown here
Re^5: Test::More and is_array by stvn (Monsignor) on Jun 11, 2005 at 01:44 UTC
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. -stvn	[reply]