Re^7: Test::More and is

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.

Comment on Re^7: Test::More and is_array

Replies are listed 'Best First'.
Re^8: Test::More and is_array by geektron (Curate) on Jun 13, 2005 at 15:14 UTC
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]
Re^9: Test::More and is_array by adrianh (Chancellor) on Jun 16, 2005 at 22:30 UTC
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]
Re^10: Test::More and is_array by geektron (Curate) on Jun 17, 2005 at 05:21 UTC
i'm being ... overly paranoid because of the huge changes to the underlying database structure.	[reply]
Re^11: Test::More and is_array by adrianh (Chancellor) on Jun 17, 2005 at 21:50 UTC