in reply to Re^5: Test::More and is_array
in thread Test::More and is_array

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 ...

Replies are listed 'Best First'.
Re^7: Test::More and is_array
by adrianh (Chancellor) on Jun 13, 2005 at 11:36 UTC
    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.

[reply]
      well, calling the routine in question gives me the correct list, so i just need to check and make sure that it's populated.
[reply]
        well, calling the routine in question gives me the correct list, so i just need to check and make sure that it's populated.

        I'm probably misunderstanding, but....

        If you know it is the correct list, why do you need to check if it's populated?

        Wouldn't it be better to check for the correct list being returned anyway? Even if you are 100% certain that the current code works, you might break something later on and a more concrete test will catch that.

        Isn't a more concrete is_deeply() test is simpler to write?

[reply]

In Section Seekers of Perl Wisdom